Evolution of JD.com Delivery Review System Architecture and Storage Strategy

1 Introduction

JD Daojia is an instant retail e‑commerce platform that delivers goods to consumers and provides online fulfillment for physical stores. To support order‑completion feedback, a review system was designed and deployed.

2 Business Scenarios

The review system consists of three parts: user side, merchant side, and operations side. Users can rate merchants, logistics, and products, and can also file complaints or reports. The merchant side can view/reply reviews, submit appeals, and issue compensation coupons. The operations side handles negative‑review audits and appeal reviews.

2.1 Review Generation

After an order is marked completed, an MQ message is consumed and a record is created in the review system. Users can rate product, merchant service, and logistics within a time window; ratings affect product ranking and merchant scores.

2.2 Review Processing

Rating criteria include good (4‑5 stars), neutral (3 stars), and bad (1‑2 stars) for merchant and logistics services, as well as like (5 points) and dislike (2 points) for individual products.

3 Architecture Evolution

The system adopts a layered design: a foundation service layer (persistence, data, logic) and upper services (application, presentation) such as merchant web, operations web, and gateway. Message middleware ensures data sync, while unified monitoring, alarm, tracing, and log collection provide observability.

3.1 System Inception

Initially all data were stored in MySQL. Problems emerged: massive data growth (tens of millions of orders per month), multi‑dimensional business, high QPS, lack of high availability, and performance bottlenecks for reporting.

Measures taken: master‑slave replication with read‑write separation, later sharding, but complex SQL still impacted stability and scalability.

3.2 Diversified Storage

Analysis of data characteristics (large text, order‑level queries) led to selecting NoSQL. Elasticsearch was considered but not real‑time; Redis was too costly for large objects; HBase was chosen for PB‑scale storage, key‑value access by order ID, and high reliability via HDFS.

HBase stores full review details with order ID as RowKey, allowing fast single‑row queries.

Redis hash structures store hot statistics such as per‑store rating counts.

To avoid client blocking when fetching many keys, Redis pipeline batches commands (e.g., 20 commands per pipeline client).

3.3 Architecture Upgrade

New requirements for tag‑based search and statistics prompted adding Elasticsearch for searchable fields while keeping HBase for full review details. The combination of ES + HBase improves performance and supports high concurrency.

Deep pagination issues in ES were solved by disabling from/size beyond page 100 and using scroll or search‑after for non‑real‑time queries.

4 Outlook

The current stack includes Redis, HBase, Elasticsearch, and MySQL. To reduce component count and simplify data management, TiDB is being evaluated as a unified storage layer. Initially, MySQL binlog is synced to TiDB, and non‑core CRUD operations are gradually migrated.

Performance tests show TiDB average query latency ~5 ms versus MySQL ~12 ms, with better scalability, HTAP capabilities, and automatic horizontal scaling.

5 Conclusion

The review system’s architecture has continuously evolved to handle growing data volume and traffic, employing heterogeneous storage, read‑write separation, caching, and distributed strategies. Future work will focus on further unifying storage with TiDB while ensuring high availability and performance.