Design and Evolution of an Order Dispatch System for Instant Delivery Platforms

Dada‑Jingdong Daojia, a leading instant‑delivery platform, handles multiple order channels such as restaurant meals, fresh‑goods retail, and merchant orders, requiring a dispatch system that balances merchant expectations for timely delivery with riders' desire for efficient order grabbing.

The early system displayed all new orders in a 3‑km pool, causing riders to cherry‑pick and leading to order timeouts, merchant loss, and wasted rider effort. To address this, the platform introduced a central scheduler that evaluates rider load, delivery habits, route compatibility, and estimated store‑stay time before assigning orders.

Key data—merchant order behavior, rider delivery logs, and trajectory—are collected and mined to build rider profiles, estimate delivery times, and predict store‑stay durations. These insights feed a genetic‑algorithm optimizer that selects the best rider and notifies them via a persistent Netty connection.

As the business grew, a dedicated rider pool for large merchants was introduced, using the dispatch system only when capacity was insufficient, otherwise relying on the dedicated pool.

The dispatch model is treated as an information‑flow recommendation engine. Orders are initially polled N times before entering the pool, with each poll acting as a delayed task. Solving the timing of these delayed tasks resolves roughly half of the system’s functional challenges.

Three classic delay‑task solutions are evaluated:

Database polling – simple but puts heavy load on the DB.

JDK DelayQueue – low latency but loses tasks on restart and can cause OOM under heavy load.

Timing Wheel – an in‑memory ring buffer that efficiently manages large numbers of delayed tasks.

The timing‑wheel principle is explained: a circular array where each slot holds a list of tasks; the wheel advances by tickMs and executes tasks in the current slot. The relationship is expressed as interval = tickMs * wheelSize . Hierarchical wheels handle tasks with longer delays by promoting them to higher‑level wheels and demoting them as time progresses.

For the final implementation, the team combined the three approaches: Redis stores the task data (leveraging AOF for durability), a single‑layer timing wheel drives the schedule, and Kafka distributes the dispatch events. The design avoids using ScheduledThreadPoolExecutor to prevent excessive empty queries that would increase CPU and Redis QPS.

Specific implementation details include:

Mapping each time slot to a Redis key (e.g., dispatchTime+IP ) and placing a sentinel node to indicate pending execution.

Appending the server IP to each cache key so that in a distributed environment each instance consumes only its own tasks, reducing concurrency conflicts and achieving O(N) lookup.

Processing slot data with asynchronous threads to prevent a single slow or failed node from blocking subsequent slots.

The design acknowledges trade‑offs: IP‑based keys may miss tasks after cluster changes, and asynchronous processing can occasionally drop tasks, which are later re‑dispatched from the pool. Periodic scripts clean up and re‑assign missed orders.

In conclusion, visualizing order‑rider interactions shows that over 90% of orders are successfully dispatched and accepted. By continuously integrating big‑data analytics and AI techniques, the platform enhances order exposure and aims to become a top‑tier delivery service.