Design and Implementation of Delivery Promise Timing in ZuanZuan E‑commerce Platform

1 What is Delivery Promise Timing?

Delivery promise (or "Promise") indicates to consumers the expected arrival time of purchased goods, helping them plan and reduce waiting anxiety. Most e‑commerce platforms display it as shown below.

2 ZuanZuan's Implementation of Delivery Promise Timing

Delivery‑promise information appears on product list pages, detail pages, order confirmation, and filter options, generating very high QPS, especially during promotions.

2.1 How the Expected Delivery Time Is Designed

Example: a user (named Xiao Wang) needs to travel from Beijing to Zhengzhou by high‑speed rail. To arrive for dinner, he must catch the 13:10 G521 train, which requires ordering before 11:20. The same principle applies to the “pay before X, deliver by Y” promise shown in the app.

The end‑to‑end flow includes four modules: Order, OMS, WMS, and TMS.

Order module: creates an order after payment and sends it to OMS.

OMS module: generates an outbound order and dispatches it to the appropriate WMS.

WMS module: handles picking and prepares the package for pickup.

TMS module: coordinates with logistics partners for scheduled pickups.

Calculation logic:

Compute the time from payment to logistics pickup based on each system node.

Query the logistics provider for the estimated delivery time using the pickup time.

Examples:

Order before 7:30 am → delivery at 14:00 next day.

Order before 12:00 pm → delivery at 22:00 next day.

Order before 16:30 pm → delivery at 11:00 two days later.

2.2 Supporting Ten‑Thousand QPS

Baseline measurement shows the “fetch delivery estimate by pickup time” step is the bottleneck.

To avoid repeated heavy computation, a pre‑warming strategy stores daily estimated delivery times for each warehouse‑pickup combination in Redis.

Additional caches (local and Redis) are applied to address other latency sources, as summarized in the table below.

Query Description

Optimization

Explanation

User address conversion

Local cache

City name and code mapping stored locally

Product warehousing

Redis

Cache result in Redis after first request

Warehouse info filling

Local cache

Low‑frequency data stored locally

Pickup time matching

Redis

Configuration refreshed daily and loaded into Redis

Resulting interface latency after optimizations:

2.3 Logic and Technical Implementation of Next‑Day, Same‑Day, and Three‑Day Delivery Filters

Filtering items that support next‑day delivery requires knowing which warehouses can meet the deadline. Two steps are needed:

Tag each product with its warehouse location.

Provide the capability to query warehouses that can deliver nationwide within the desired timeframe.

Challenges include avoiding real‑time computation for thousands of warehouses. The solution extends the pre‑warming task to generate separate indexes for each delivery‑time type, storing them in Redis as key‑zset structures, enabling fast range queries.

Further refinements replace key‑list with key‑zset, aggregating all warehouse batches (latest payment times) as scores, allowing efficient retrieval of supporting warehouses without large keys.

3 Conclusion

The ZuanZuan delivery‑promise system demonstrates a strong focus on user experience, from precise delivery‑time calculations to high‑concurrency handling and continuous optimization of delivery‑type filters, aiming to provide a reliable shopping environment.

As e‑commerce competition intensifies, delivery promise becomes a critical differentiator, and ZuanZuan will keep enhancing the system to meet growing user expectations.

About the author

Wang Peng, backend engineer responsible for OMS and delivery‑promise systems at ZuanZuan.