DoorDash Dispatch: Matching as an Optimisation Problem
also called Deep Red, Assignment Optimisation
Assigning deliveries greedily to the nearest driver is locally sensible and globally poor, so the assignment is batched and solved as an optimisation.
The problem
A delivery marketplace must continuously match orders to available drivers. The obvious approach is greedy: when an order is ready, assign the nearest available driver.
Greedy assignment is locally optimal and globally poor. Assigning the nearest driver to the first order may strand a second order with no nearby driver. It ignores the possibility of batching two deliveries going the same way. It does not account for how long food will wait, or for where drivers will end up and whether that leaves the network positioned for the next wave of demand.
What they did
DoorDash's dispatch system treats assignment as an optimisation over a batch rather than a sequence of independent decisions. Orders and drivers are considered together over a short time window, and the system solves for an assignment that optimises a combined objective — delivery time, driver utilisation, food freshness, and the positioning of supply for subsequent demand.
This depends on several supporting predictions: how long the restaurant will take, how long the drive will take given current conditions, and where demand is likely to appear.
The trade-off
Waiting to batch adds latency. A decision deferred by even a short window improves the assignment and delays the delivery, and that window is a tuned parameter balancing global efficiency against individual experience.
Optimisation is also computationally expensive and must complete within the window, at scale, which constrains how sophisticated the objective can be. And it is far harder to explain: when a driver asks why they were not given the nearest order, "an optimiser decided" is an unsatisfying answer with real consequences for trust.
The transferable lesson
Greedy local decisions produce poor global outcomes whenever resources are contended, and the remedy — batching and optimising over a window — trades latency for quality.
The pattern recurs well beyond delivery: scheduling jobs onto compute, assigning support tickets, placing replicas across nodes, allocating inventory across warehouses, matching riders to drivers.
The design question to ask: is each decision independent, or does it consume a resource another decision needs? If the latter, a greedy algorithm is leaving value on the table, and the size of the batching window is the dial between responsiveness and efficiency.