Design DoorDash — System Design Interview Guide

Functional requirements

• Browse restaurants near my delivery address with menus, ratings, and estimated delivery time
• Place an order with multiple items, optional special instructions, and tip
• System routes the order to the restaurant POS and matches a courier
• Track the order end-to-end: placed, accepted, prepared, picked up, en route, delivered
• Pay via stored payment method; handle order modifications and refunds
• Rate the restaurant and courier post-delivery

Non-functional requirements

• Scale: ~30M MAU US, ~500K active couriers, ~2-3M deliveries/day peak
• Restaurant discovery latency: <500ms p99 to load the restaurant list for an address
• Order placement latency: <2 sec p99 from tap to confirmation
• Courier-match latency: <30 sec p99 from order accepted to courier assigned
• Availability: 99.95%; degraded discovery (smaller restaurant set) acceptable, full outage not
• Delivery-time prediction: estimated time should be within 10 minutes of actual for 80%+ of orders

Capacity estimation

Public scale anchors (DoorDash 2023): ~30M MAU in the US, ~2-3M deliveries/day, ~500K active couriers, ~500K active restaurant partners. Daily orders ~3M/day = ~35/sec average, ~200/sec peak (lunch and dinner rushes).

Write QPS: orders ~200/sec peak, courier location pings ~500K couriers × 1 ping / 5 sec = ~100K writes/sec, order-status events ~10 events/order × 3M orders/day = 30M events/day = ~350/sec average. Reads dominate: restaurant-list page loads ~50M/day = ~600/sec average, ~5K/sec peak; order-tracking views ~100M/day (each order is tracked many times).

Storage: restaurant catalogs ~10 KB/restaurant × 500K = ~5 GB; menu items ~500 bytes × ~50M items = ~25 GB. Order records ~2 KB/order × 3M/day = 6 GB/day = ~2 TB/year. Courier location history at 100K writes/sec × 100 bytes × 86,400 sec = ~860 GB/day raw, retained 30 days hot then sampled.

Geospatial complexity: each delivery address has a different set of available restaurants depending on the courier-supply radius and restaurant delivery zones (typically 5-7 km from the restaurant). Coverage is precomputed per H3 or geohash cell.

High-level design

Five core services, with the three-sided coordination as the central problem.

Marketplace service handles consumer discovery. For a delivery address, it queries a geospatial index of restaurants within the delivery radius (typically 5-7 km), filters by open-now and accepting-orders, and returns a personalized ranked list. Restaurant data is cached aggressively because the same restaurant is browsed by thousands of nearby users.

Order service writes the canonical order record to a sharded relational store on placement, then orchestrates the order lifecycle. It posts the order to the restaurant POS via a restaurant-integration layer (each chain has its own POS protocol), waits for acceptance, and emits a 'ready for courier match' event when the restaurant accepts.

Matching service handles courier assignment. It runs separately from the order service so courier supply-demand state can be optimized independently. When an order becomes match-ready, the matcher considers nearby idle couriers, estimated restaurant preparation time, and a courier's existing delivery queue (some couriers batch multiple orders). Match latency must be low to keep food fresh.

Location ingest: couriers send GPS pings to a regional ingest service that updates an in-memory geospatial index of (courier_id, location, status, current_order_count). This is the same pattern as ride-hailing, with the addition of a 'current_order_count' to support batched deliveries.

Restaurant integration: a separate service maintains POS connections to restaurant systems. For chain restaurants it integrates with the chain's central POS API; for independent restaurants it pushes orders to a tablet running a DoorDash partner app. Order acceptance, preparation status, and 'ready for pickup' events flow back into the order service.

Lastly, an ETA service combines restaurant preparation models (historical prep time by restaurant, by hour, by order size) and courier travel models (geospatial distance plus traffic) to predict the customer-facing delivery estimate.

Deep dive — the hard problem

Two deep dives: the three-sided coordination problem and the ETA prediction.

Three-sided coordination: the unique challenge of food delivery vs ride-hailing is that the order takes 15-30 minutes to prepare and the courier should arrive at the restaurant approximately when the food is ready — not before (courier waits, wasting time) and not after (food sits, gets cold). Production systems use a 'just-in-time' assignment that incorporates predicted preparation time.

Here is the central tactic: don't assign a courier the moment the order is placed. Instead, hold the order, predict when it will be ready, and assign a courier whose ETA at the restaurant aligns with the readiness time. The matcher computes a target-pickup window per order, then matches against couriers whose predicted-arrival-at-pickup falls in that window. Couriers with multiple in-progress orders are still candidates — their availability is predicted from their current trip plus pickup-time.

This batching introduces a tradeoff: a courier can pick up two orders at the same restaurant if they're ready simultaneously, saving driver time but adding complexity. Production matchers use a constrained optimization: for the set of pending orders + idle couriers in a region, compute an assignment that minimizes total weighted cost (food-wait time + courier-wait time + customer-wait time). This is a vehicle routing problem variant solved heuristically because it's NP-hard in general.

Second deep dive: ETA prediction. The customer-facing 'arrives in 25-35 minutes' estimate is the most visible part of the product, and getting it wrong (especially too-optimistic) is the biggest source of user complaints. Production ETA = food-prep time + courier-travel-to-restaurant + restaurant-wait time + courier-travel-to-customer + handoff time.

Each component has its own model. Food-prep time is the hardest — it varies by restaurant (some are 10 min, some are 40), by order size, by time of day (peak vs slow), and by current restaurant backlog. The model is trained on historical data: features include restaurant ID, hour of day, order item count, current queued orders at that restaurant. Each restaurant has its own backlog state tracked in memory.

Courier-travel uses standard ETA models (geospatial distance plus traffic factor by time of day). Restaurant-wait is a small constant plus a percentile of historical wait times for that restaurant. Handoff time is roughly fixed (~2-3 minutes).

The overall ETA includes uncertainty: production systems often present a range (25-35 minutes) rather than a single number, because the variance compounds. Internal predictions track P50 and P90; the customer sees a range corresponding to roughly P50 to P90.

Third tradeoff: handling restaurant rejection. Restaurants can reject orders (out of stock, kitchen closed unexpectedly). The order service must handle this gracefully — refund the customer, notify them, and offer alternatives. This isn't an edge case; rejection rates of 2-5% are typical. Production designs treat order acceptance as the first lifecycle gate, with the matching pipeline downstream.

Common mistakes

• Assigning a courier the moment an order is placed — produces couriers waiting at restaurants for food that isn't ready
• Skipping the food-preparation time model — without it, ETAs are wildly inaccurate and courier scheduling fails
• Treating ETA as a single number instead of a P50/P90 range — variance is large and a too-optimistic estimate damages the customer relationship
• Designing matching as nearest-courier — ignores existing courier queues and the batched-pickup case
• Ignoring restaurant rejection — at ~3% rejection rates the failure path is the second-most-common outcome

Likely follow-up questions

• How would you design the courier batching strategy to balance throughput against customer wait time?
• What changes if you have to support grocery delivery where orders take much longer to assemble (45+ minutes)?
• How would your design handle a city-wide weather event that drops courier supply by 70%?
• How would you detect and prevent courier fraud (couriers marking orders delivered without actually delivering)?
• How would you implement personalized restaurant recommendations on the home screen?