How DoorDash Built a Next-Generation Real-Time Dispatch Platform

TL;DR — This post describes how DoorDash rearchitected its real-time dispatch system. At peak, demand was nearly four times the dispatch processing capacity, forcing the system to make decisions on incomplete information. The underlying algorithms scaled quadratically, meaning even modest volume growth translated into outsized runtime pressure. The new architecture transformed the system from a growth-constrained centralized execution model into a distributed, scalable, machine-learning-ready platform — improving throughput ten-fold, achieving 99.9% of runs under 20 seconds, and improving on-time delivery performance. We focus here on the engineering problem behind dispatch at high scale, why simple horizontal scaling was not enough, how the decoupled coordinator-compute architecture changed the scaling curve of dispatch, and what we learned about building critical-path systems that must balance optimization quality, latency, reliability, and long-term extensibility.

Space, Time, and the Logistics Chessboard

DoorDash's real-time dispatch system is the beating heart of our logistics network. Every second, it makes millions of micro-decisions, matching available Dashers with incoming consumer orders to ensure fast, reliable deliveries.

To understand the sheer magnitude of this challenge, it helps to look at the classic Traveling Salesperson Problem (TSP) and the Vehicle Routing Problem (VRP). In a textbook TSP, the goal is simply to find the shortest possible route to visit a fixed set of cities.

But our dispatch engine doesn't operate on a static map; it plays a highly constrained, multi-dimensional game of chess governed by two unforgiving variables: Space and Time.

• Space: We must constantly evaluate the dynamic geographic distribution of tens of thousands of Dashers, the static locations of merchants, and the final consumer destinations across thousands of local markets.
• Time: This is our ultimate constraint. Unlike delivering packages that can arrive any time before 8 p.m., delivering a hot pizza or melting ice cream has a razor-thin margin of error. We must perfectly synchronize Dasher travel velocities and real-time traffic patterns with highly variable merchant food preparation times.

As our business continues to experience hypergrowth, the complexity of solving this spatial-temporal puzzle in real time has grown superlinearly. Here we detail our journey of migrating from a legacy dispatch engine to a newly architected, highly scalable distributed platform that not only solved our immediate dispatch problems but also offers long-term solutions for the future.

The Bottleneck: Outgrowing the Monolith and the Speed of Reality

The previous generation of our dispatch engine served us well during our earlier growth phases. It was, however, built as a monolithic system in which business logic, state management, and heavy mathematical computations were tightly coupled.

In a dynamic routing problem, adding a few more stops doesn't simply add a few more calculations; it triggers a combinatorial explosion. The fundamental algorithms powering the legacy engine operated with a time complexity of roughly O(N²). During average hours, this quadratic scaling was manageable. But over time, as our network density compounded, the system began to encounter a fundamental structural limit.

During extreme peak hours – such as a Friday night dinner rush or Super Bowl Sunday – demand would far exceed dispatch processing capacity. More deliveries did not simply mean proportionally more work; they quickly expanded the search space of possible assignments and drastically increased the coordination required inside each decision cycle. The legacy monolith found itself forced to evaluate tens of millions of potential Dasher-to-Order combinations within seconds, often degrading into fallback heuristics and decisions made on incomplete information.

The fatal bottleneck wasn't just raw machine capacity; it was the speed of reality. When network density spiked, the legacy engine's computational latency would stretch. But if the engine takes several minutes to calculate the "mathematically perfect" dispatch solution, that solution is already obsolete by the time it is emitted. Dashers have driven past optimal intersections, new high-priority orders have dropped, and food has been sitting on the counter. This lag triggered a cascading failure — delayed algorithm execution led to missed real-world time windows, suboptimal routing, and elevated cancellation rates.

Faced with this, the intuitive engineering response is naïve horizontal scaling — simply throw more hardware at the problem. But real-time dispatch is not a stateless web workload where requests can be blindly split evenly across more machines while the system is expected to behave the same way. The optimization space is inherently interconnected. If the partitioning strategy loses important structural context, optimization quality — like batching efficiency — severely suffers. Conversely, if the workload is split incorrectly, we merely trade compute bottlenecks for new choke points in orchestration, state aggregation, or duplicated computation.

We had reached the limits of incremental tuning. The bottleneck was no longer just local inefficiency; the very shape of the computation itself had become untenable at high volume. We realized that simply throwing more hardware at a monolithic architecture couldn't outrun a superlinear curve. To scale into the future, the system didn't just need more capacity – it demanded a fundamentally new execution model.

Shattering the Monolith: Orchestration Meets Distributed Compute

To break free from the structural limitations of the legacy monolith, we designed the next-generation dispatch platform around a single engineering philosophy: a clear separation of coordination and computation. We completely decoupled the monolithic engine into two distinct, independently scalable tiers:

• Coordinator tier: The orchestrator is a stateful, highly available component responsible for managing the lifecycle of the dispatch process, maintaining the global state of the logistics network, and validating complex business rules.
• Distributed compute tier: The compute nodes are stateless, ultra-high-performance workers optimized solely for crunching mathematical models, executing vehicle routing heuristics, and processing model inference. Figure 1 contrasts the two topologies.

Because the coordinator and compute nodes are decoupled, they require ultra-fast, intelligent data distribution. To minimize network overhead, the coordinator does not broadcast the massive global state to the entire compute pool. Instead, it leverages a highly optimized localized payload sharding mechanism over gRPC. On every dispatch tick, the coordinator streams the specific localized sub-portion (cluster context) required for a given compute node's optimization run. This targeted, self-contained data distribution drastically reduces network bandwidth, keeps communication latency low, and ensures that the compute nodes remain strictly stateless. Figure 2 shows how serial execution gives way to parallel fanout and reconciliation.

Changing the Scaling Curve with Hierarchical Decomposition

Decoupling the architecture solved the infrastructure bottleneck, isolating our compute workloads, but the underlying mathematical O(N²) complexity remained. To address this within the distributed compute nodes, we introduced hierarchical decomposition.

Instead of attempting to solve a massive, interconnected global optimization matrix in a single monolithic pass, the coordinator intelligently partitions the global state into highly localized, dense geospatial clusters and delivery trajectories. By dividing the problem into independent, localized sub-problems, the new architecture can execute optimization routines in parallel across a horizontally scalable pool of compute workers. Figure 3 traces one run through both decomposition stages.

After the localized solutions are calculated, a specialized global reconciliation layer merges results across the sub-problem boundaries. This ensures that while the computation is distributed and accelerated, the final routing decisions preserve much of the optimization quality of the original problem while allowing the expensive candidate-generation work to execute in parallel.

Building for a Critical Path: Validation, Rollout, and Reliability

Replacing the core dispatch engine of a massive, real-time logistics network is the engineering equivalent of swapping out a jet engine mid-flight. System downtime or suboptimal dispatching would immediately translate to lost revenue for merchants and poor experiences for consumers. Reliability was paramount.

To guarantee a seamless transition, we engineered a rigorous shadow testing framework. In shadow mode, production traffic was duplicated in real time. As incoming dispatch triggers arrived, the coordinator forked the requests, routing one copy to the legacy dispatch engine while a duplicate payload went to the new distributed platform (Figure 4).

The legacy system's output dictated the actual real-world dispatch, while the new platform's output was logged and analyzed. This allowed us to perform extensive, side-by-side behavioral regression analysis on match quality, delivery times, and system resilience under peak production pressure without risking any actual deliveries.

After establishing parity in shadow mode, we gradually moved to production switchback experiments, using controlled exposure and fallback mechanisms to validate both system reliability and real-world fulfillment metrics before we expanded to the rollout.

Impact and Results

The production rollout demonstrated substantial improvements in scalability, runtime, and fulfillment efficiency. We fundamentally redefined our operational capabilities, shifting from a monolithic, superlinearly scaling engine to a highly parallelized distributed platform.

During our global experiment launch, the new architecture unlocked massive systemic efficiencies by enabling single-digit-second optimization at a significantly larger scale (Figure 5). By evaluating a vastly larger search space without the arbitrary limiters of the past, the new architecture improved Dasher acceptance rates, enhanced overall fulfillment efficiency, and boosted Dasher earnings. At DoorDash's scale, these micro-optimizations compound exponentially, translating into millions of dollars in annualized fulfillment savings while simultaneously improving Dasher utilization and platform economics.

The ultimate test of the new platform's resilience came during extreme peak events, such as Super Bowl Sunday. Historically, massive traffic spikes would force the legacy system to hit hard volume limiters, stretching runtime to minutes and degrading assignment quality. With the distributed compute architecture, the system maintained more than 99.99% availability despite a 10% week-over-week surge in peak volume. We successfully eliminated the runtime cliff, proving that our platform can scale horizontally without sacrificing optimization quality.

Future-Proofing: A Platform for ML and RL

The new architecture is not just a solution for today's volume; it provides the foundational infrastructure required to usher in the next era of DoorDash logistics — scalable RL and machine learning (ML).

Previously, embedding computationally expensive deep learning models directly into the dispatch loop was impossible due to the monolithic constraints of the legacy engine. To solve this, the next-gen platform introduced a hybrid L1/L2 model serving architecture integrated directly into the distributed compute tier.

L1 Local serving (ONNX runtime): For high-cardinality, extreme latency-sensitive evaluations, we embedded local ONNX runtime engines directly inside each individual compute node. This setup allows the compute tier to execute millions of highly concurrent local inferences at single-digit-millisecond latency, without RPC overhead. Crucially, this L1 tier runs both our structural route feasibility scoring models and our real-time RL agents.

L2 Remote serving (machine learning platform): For more complex, lower-cardinality policy evaluations, the orchestrator seamlessly calls isolated remote machine learning serving clusters, ensuring heavy ML workloads do not disrupt the critical state-management path. Figure 6 shows both serving tiers.

This infrastructure also enabled us to deploy more computationally intensive ML and RL models directly in the dispatch loop. Leveraging this new architecture, we successfully deployed a multi-agent reinforcement learning system to dynamically adapt dispatch objective weights. Instead of relying on static, globally tuned heuristics, our decentralized RL agents observe localized, delayed marketplace feedback — such as merchant congestion and courier utilization — to dynamically shift the optimizer's tradeoff between delivery speed and batching efficiency at the individual store level.

This work not only significantly improved system efficiency during production switchback experiments but was also recently accepted at the ICML 2026 Workshop on Reinforcement Learning from World Feedback (RLxF). For more details, see our companion post, How Aligning Dispatch to Reality: Using Reinforcement Learning to Adapt Real-Time Objective Weight. By stabilizing the core platform with the distributed architecture, we have bought the "right to build" the future – transforming dispatch from a rigid rules engine into an adaptive, AI-driven logistics ecosystem.

Conclusion

The biggest contribution of the new platform was not one isolated performance gain. Indeed, it has changed the long-term trajectory of dispatch.

The legacy system was approaching a point where growth would increasingly translate into runtime pressure, operational strain, and architectural fragility. The new architecture changed that path by introducing a more scalable execution model and a cleaner systems foundation. But its long-term value goes beyond solving the immediate scaling problem. With a more distributed, modular, and scalable platform in place, DoorDash can continue iterating on richer optimization strategies, more adaptive decision-making, and deeper ML- and RL-driven dispatch capabilities. It also creates a path toward broader platformization, allowing dispatch to evolve as an extensible system layer rather than a single, tightly coupled engine.

That is why this next-generation architecture matters beyond a single redesign. Its value is not only that it removed a bottleneck, but that it expanded what the system can become next. The most meaningful engineering wins do not just improve one benchmark. They change the slope of the problem and create the foundation for future intelligence, flexibility, and growth.

Acknowledgments

This massive rearchitecture was made possible by the contributions of many engineers, scientists, product partners, and leaders across DoorDash.

We would like to thank Fan Peng, Kali Sharma, Lily Xie, Reid Arwood, Sifeng Lin, Sinan Xiao and many others for their work across architecture, implementation, benchmarking, validation, and rollout. We also thank David Chen and Eric Bencomo Dixon for strong cross-functional partnership and support. We are thankful to Gayatri Iyengar and Xiao Li for their sponsorship and leadership, and to Yuke Yang, Jun Jin, Matt Zimmerman, and Sonic Wang for the fruitful discussions and guidance that helped move this work from concept to reality.