How to Build a Scalable Intelligent Dispatch System for 400K Daily Orders

Stone Age: Single Database and Business Decoupling

In the early stage, the platform launched within three weeks with three modules (user app, merchant app, admin backend) sharing a single database to reduce cost and quickly validate market demand.

The dispatch logic was handled by OrderPushJar, which created and pushed orders via MQTT to all drivers in a predefined radius, offering subsidies to accelerate market capture but causing significant waste.

Rapid growth soon exposed database bottlenecks such as field redundancy and ineffective indexing, limiting multi‑business support.

The solution split the monolithic database into independent databases per module (order, settlement, configuration, tracking) using bidirectional synchronization to enable zero‑downtime migration.

Iron Age: Dual Push Channels and Quadrant Dispatch

As competition intensified, the platform introduced multiple push channels (self‑built TCP, GeTui, MiPush) and a quadrant‑based dispatch strategy. Orders were first pushed to drivers within a certain radius; if unclaimed, subsidies increased and the search expanded to larger quadrants.

Driver assignment considered distance, rating, and historical completion rate, reducing ineffective subsidies and improving order completion.

Smart Age: Big‑Data Platform and Intelligent Dispatch

From 2016, the focus shifted to efficiency. A big‑data platform was introduced to collect logs from apps, H5, and servers via Flume and Kafka, while DB changes were captured through DTS and Canal.

Collected data fed an XGBoost‑based model that normalized features, performed bucketization, and generated ~800,000 trained models for order pricing, driver selection, and subsidy optimization.

Scenario 1 – Pricing

The model balances user discount A, driver subsidy B, base price C, and platform commission D, aiming to minimize A and B while maintaining a high order‑grab rate.

Scenario 2 – Order Push

Using logistic regression, the system predicts each nearby driver’s willingness to accept an order based on distance, price, tip, and start/end points, then pushes orders through the optimal channel.

Scenario 3 – Driver Selection (Middle Order)

When dozens of drivers compete, the system evaluates rating, distance, service attitude, and willingness to perform extra tasks to select the optimal driver.

Scenario 4 – Overall Operations

The platform applies the pricing model at order creation, predicts driver acceptance and push order, dynamically adjusts subsidies based on real‑time driver response, forecasts driver completion probability, and monitors user churn to issue targeted coupons.

Monitoring and Governance

A dedicated monitoring platform tracks algorithm stability, business volatility, and issue‑resolution efficiency. It observes JVM, CPU, thread, cache, DB metrics, as well as order and subsidy fluctuations, issuing alerts for abnormal spikes such as sudden coupon order surges.

Key Takeaways

Align architecture and team with business needs to sustain rapid evolution.

Adopt dual push channels to ensure high delivery rates.

Implement real‑time monitoring to detect and resolve issues instantly.

Continuously upskill the team to keep pace with business growth.