Design a Food Delivery System: DoorDash Engineering Under the Hood

30 Minutes From Order to Doorstep

DoorDash coordinates 25 million monthly orders across three parties simultaneously: a customer who wants food fast, a restaurant preparing the food, and a dasher driving to deliver it. The promised delivery time shown before checkout combines three ML predictions: restaurant prep time (learned from millions of past orders), dasher travel to restaurant, and dasher travel to customer. If ANY prediction is wrong by even 5 minutes, customer satisfaction drops dramatically. This three-sided real-time coordination makes food delivery one of the hardest logistics problems in tech.

Order Lifecycle

Order Flow (30-Minute Target):

  t=0:00  [Customer] places order
          ACID transaction: charge card, create order
               |
  t=0:01  [Restaurant Tablet] receives order via WebSocket
               |
  t=0:02  [Dispatch] finds nearest dashers
          S2 cell geospatial query in Redis
          Score: ETA * 0.5 + rating * 0.3 + stacking * 0.2
               |
  t=0:05  [Dasher] accepts delivery offer
               |
  t=0:05-0:20  Restaurant prepares food
               (ML-predicted prep time per restaurant)
               |
  t=0:15  [Dasher] arrives at restaurant
          (dispatched to arrive when food is ready)
               |
  t=0:20  [Dasher] picks up food
               |
  t=0:25  [Dasher] delivers to customer
               |
  t=0:26  [Customer] rates experience
          Rating feeds back into ETA model training

Dasher Dispatch Optimization

Dispatch is NOT just 'find nearest dasher':

  Naive: assign closest available dasher to each new order
  Problem: globally suboptimal (dasher A is closer to order 1,
           but assigning dasher B to order 1 AND dasher A to
           order 2 minimizes TOTAL delivery time)

  DoorDash's batching algorithm considers:

  1. Order stacking:
     Two orders from restaurants 200m apart?
     -> One dasher picks up both (saves a whole trip)

  2. Direction awareness:
     Dasher heading north with current delivery?
     -> Assign next northbound order, not a southbound one

  3. Prep time alignment:
     Restaurant A: food ready in 5 min
     Restaurant B: food ready in 20 min
     -> Don't dispatch to B yet (dasher waits 15 min)
     -> Assign dasher a closer order first, then B

  This is a combinatorial optimization problem
  re-solved every 30 seconds across all pending orders

Interview Tip

When designing a food delivery system, emphasize: (1) ACID transactions for order placement (charge card + create order atomically), (2) real-time WebSocket connections for all three parties, (3) dispatch as a batching optimization problem (not just nearest-neighbor), (4) ML-predicted ETAs combining restaurant prep time (per-restaurant model) + routing travel time. The hardest part is timing dasher arrival to match food readiness.

<

/blockquote>

Key Takeaway

Food delivery systems coordinate three actors via WebSockets and real-time location tracking. ETA accuracy requires ML models combining prep time history with routing APIs. Dasher dispatch is a combinatorial optimization problem, not just nearest-neighbor assignment. ACID transactions protect the order placement critical path.