DoorDash: Logistics Optimization for On-Demand Delivery
DeepRed turns marketplace predictions into coordinated delivery offers.
This is not a project for a KarmaKoders client but an independent teardown of public engineering disclosures from DoorDash. It discusses the architecture as described in 2020-2021; it does not claim to have access to the production stack of today.
DoorDash connects consumers, merchants, and Dashers. In August 2021, it published a piece about millions of daily orders. The dispatcher needs to balance travel, food readiness, availability of couriers and uncertainty of acceptance. If a long wait is the price of arriving early, the closest courier is not necessarily the best. Source: DoorDash DeepRed overview.
The architectural problem is how to convert uncertain predictions into a coherent set of actions. Our analysis focuses on that decision boundary and the evidence required to change it safely for couriers.
Rendering diagram…
Before
The previous optimizer used bipartite matching and the Hungarian algorithm, where one delivery was assigned at a time to a route. The formulation was limited by large instances and complex multi-delivery routes. The existing optimizer was controlling real-time dispatch decisions.
After
The mixed-integer programming, or MIP, formulation enabled more flexible routing models. DoorDash picked Gurobi after testing CBC, XPress, CPLEX and Gurobi. The live results were still run by the original optimizer, the optimizer using parallel output comparison.
Decisions
Estimate independently of allocation. The published DeepRed pipeline provides estimates of readiness, travel, and acceptance for candidate offers. Optimization then considers efficiency and quality of delivery—batching, holdback of dispatch, etc. Source: DeepRed architecture
Select the solver for the actual task. DoorDash’s published selection considered speed, scalability, feasible solutions, integration, licensing, and support. Source: Optimizer Migration. Our take-away: treat a benchmark as a buying decision only after testing representative traffic and operational constraints.
Test marketplace changes at an appropriate unit. DoorDash said that users share a common pool of couriers and can influence one another, so it’s impossible to compare them in isolation. The switchback design randomized treatment across geographic areas and time windows. DoorDash switchback experiment
Don’t mix technical equivalence with business improvement. We interpret shadow comparison as answering the question of whether a substitute is behaving as expected. It does not say if a new policy is better for the marketplace. That's a different assessment with defined outcomes and guardrails.
For a smaller delivery startup, we would instrument order creation, readiness for pickup, offer responses, and completed deliveries first. Begin with a baseline you understand. Review the failed assignments. Don’t try to copy the complexity of an existing platform. Add more advanced optimization when you have evidence of bottlenecks that justify it.
type Candidate = Readonly<{
id: string;
courierId: string;
orderIds: readonly string[];
score: number;
}>;
interface Optimizer {
solve(
candidates: readonly Candidate[],
deadlineMs: number
): Promise<{
selectedIds: string[];
status: 'feasible' | 'infeasible' | 'timeout';
}>;
}Schedule on Cal.com
Looking for a on demand delivery product? Talk about dispatch boundaries, operational metrics, and a first release that is achievable with KarmaKoders.
Next step
Book a 15-min Architecture Review
Walk through your system with a lead architect and leave with a scoped recommendation.
Schedule on Cal.com