DoorDash / UberEats

Food delivery

Design a food delivery marketplace where customers order from restaurants, the platform picks a driver for each order, and everyone sees the order move from kitchen to door.

Overview

A food delivery platform serves three groups at once: customers who order, stores that cook, and drivers (DoorDash calls them Dashers) who carry the food. An order is a small workflow that runs for about half an hour: pay, send to the store, find a driver, pick up, drop off. Everyone involved watches it happen.

The hard part is not taking orders; at a few hundred a second, that is modest. It is the dispatch decision: which driver should take which order, and when to send them, so food is not left waiting and drivers are not left waiting either. That decision rests on predictions (when will the food be ready, how long will the drive take) and on a live picture of where every driver is, fed by a constant stream of location updates.

Questions to ask first

How many orders? — 6 million a day, peak 3 times the average at dinner
How many drivers? — 400,000 active at peak, each sending a location every 4 seconds
How long is a delivery? — About 40 minutes from order to door
Can a driver carry several orders? — Yes; batching orders from the same or nearby stores
Can drivers decline? — Yes; an offer goes to one driver, who accepts or declines
What does the customer see? — Order status, the driver on a map, and an ETA

What you will be able to do

Run an order as a durable state machine with retryable, idempotent steps.
Ingest driver locations and find nearby drivers fast.
Explain dispatch as a regional optimization over predictions, with batching and delayed dispatch.
Describe ETAs as probability distributions rather than single numbers.
Handle dinner rush and bad weather on the supply side.

Key concepts

Three-sided marketplace
Order state machine
Location ingestion
Geo index of drivers
Dispatch as optimization
Batching
Delayed dispatch
Probabilistic ETA
Peak pay

Functional requirements

Customers browse stores that deliver to them and order from a menu
The order is paid, sent to the store, and confirmed
The platform offers the delivery to a driver, who accepts or declines
Drivers can carry more than one order on a route
Customers see status, the driver's location and an ETA until drop-off
Stores see when the driver will arrive

Non-functional requirements

Placing an order returns in under 2 seconds (a target we chose)
An accepted order is never lost, even if a service fails mid-flow
A driver's position reaches the customer within about 5 seconds (a target we chose)
Dispatch decisions for a region are recomputed several times a minute
One region's problems do not spread to other regions

Interview questions

How does dispatch choose a Dasher for an order?
Why not just use the Hungarian algorithm?
How do you handle 100,000 location updates a second?
How do you make sure an order is never lost between services?
How do you predict and show the ETA?
Why would you delay sending a Dasher?
What happens at dinner rush or in bad weather?
How do you stop two Dashers from taking the same delivery?