Design and Iteration of JD Daojia Order Timeliness System

Background

JD Daojia is an instant retail e‑commerce platform that offers a one‑hour delivery service; order timeliness is a key factor. The timeliness system calculates fulfillment time for each order and provides results to shopping cart, checkout, order creation, after‑sale, recommendation, and other systems.

Forward fulfillment: compute time needed for each production stage and return to store list, cart, order system to manage user expectations.

Reverse fulfillment: calculate after‑sale order timeliness and return to after‑sale systems.

Fulfillment guarantee: adjust timeliness when store capacity is insufficient due to weather, traffic, promotions, pandemic, etc.

Overall System Architecture

1. System Architecture

The system consists of a calendar calculation service, cache, worker, message queue, monitoring, and log management components.

Component overview:

Monitoring: unified monitoring and alert platform with second‑level monitoring, multi‑dimensional monitoring, alerts, and full‑link tracing.

Log management: log collection and query service.

Message middleware: JD’s MQ middleware for decoupling and asynchronous data sync.

Worker: TBSchedule distributed scheduling engine for task distribution and execution.

Configuration management: JD‑home‑grown unified configuration component.

Storage: JVM cache, Redis cache, database.

2. Upstream and Downstream Relationships

During order creation, the timeliness system interacts with stores, products, real‑time data, etc., obtains data for calculation, and serves results to store list pages, product detail pages, order creation, after‑sale, and other systems.

Timeliness System Iterations

1. Early Timeliness

When order volume was low, timeliness relied only on store configuration, using “order timeliness” and “fixed‑interval” settings. Estimated delivery = current time + order timeliness.

2. Problems Caused by Business Growth

Increasing order volume exposed issues: inaccurate delivery timeliness, unclear responsibility for overdue fulfillment, unreasonable rider delivery time, insufficient timeliness factors (weather, capacity, promotions, etc.), and coarse‑grained hour‑level timeliness.

3. Timeliness Iteration to Solve Problems

To address the above, the system was iterated:

Added “picking duration” configuration to clarify responsibility for picking delays.

Calculated rider delivery time based on distance between store and customer, improving accuracy.

Introduced additional factors such as adverse weather, insufficient capacity, difficult delivery POI, holidays, etc.

Switched to minute‑level granularity for finer timeliness.

4. Improving Fulfillment Rate

During peak promotions, stores may be overloaded, leading to low fulfillment. The system adds order‑control (控单) capability.

4.1 Manual Order Control

When real‑time order volume exceeds configured control threshold, the time slot is blocked, steering orders to less busy periods.

4.2 Automatic Order Control

An intelligent algorithm automatically generates control settings based on real‑time fulfillment metrics, reducing manual effort while still having some latency.

5. Product‑Dimension Timeliness

Support for processing‑type products (e.g., cakes) with additional processing time, pre‑sale items with pre‑sale timeliness, and multi‑SKU orders with extra picking delay.

6. Final Business Architecture

The system now consists of three core logics: merchant picking fulfillment (including product type, processing, pre‑sale), delivery fulfillment (distance, weather, POI), and fulfillment guarantee (promotion spikes, store capacity, transport capacity) by adjusting timeliness.

Summary

As business grows, user expectations for timeliness increase; the system continues to evolve, incorporating big‑data and machine‑learning techniques to predict timeliness more accurately and move toward smarter, finer‑grained fulfillment.