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

Author Introduction : Ji Bingkun – Java engineer responsible for order distribution, permission management, order merging, and related tasks.

Background : Dada‑JD Daojia is a leading instant‑delivery platform handling multi‑channel orders (food, fresh goods, merchant orders). To improve user stickiness, the system must balance merchant expectations for timely delivery and rider expectations for efficient order grabbing.

Problem Statement : Early in the product lifecycle, orders appeared directly in a grab‑pool, allowing nearby riders to see them. This “brute‑force” display caused riders to cherry‑pick profitable orders, leading to order timeouts, merchant churn, and wasted rider effort.

Core Questions identified for a smarter dispatcher include rider load, delivery habits, route compatibility, store‑stay time estimation, etc.

System Evolution : The platform moved from pure grab‑pool display to a system‑driven dispatch model, recording merchant order behavior and rider logs, applying data mining to build rider profiles and time estimates, and using genetic algorithms for optimal routing.

Delay‑Task Solutions Explored :

Database Polling : Simple with Quartz but puts heavy load on the DB.

JDK DelayQueue : In‑memory, low latency, but loses data on restart and may cause OOM under heavy load.

Timing Wheel : Efficient hierarchical wheel storing tasks in memory; requires custom persistence for high availability.

Final Implementation : Combine Redis (AOF persistence) as the task store with a single‑layer Timing Wheel to drive time progression. Redis decouples storage from timing, avoiding data loss. Kafka is used for massive delayed‑task handling, but only a single‑layer wheel is needed for this use case.

Key Design Details :

Map each time slot to a sentinel node in Redis (key = dispatchTime+IP) to indicate pending tasks.

Prefix cache keys with the server IP to ensure each instance consumes only its own tasks, preventing concurrency issues in a distributed environment.

Process tasks from each slot with asynchronous threads to avoid blocking the next tick if a previous task fails or times out.

Considerations : Using IP‑based keys may cause missed consumption after cluster changes; async thread pools may also drop tasks. Unconsumed tasks fall back to the grab‑pool, and periodic scripts re‑dispatch them.

Conclusion : Visualized metrics show over 90% of orders are successfully dispatched and accepted by riders. The dispatch model, enhanced with big‑data and AI techniques, remains a vital technical lever for improving order exposure and platform performance.