Inside JD.com’s Review & Share System: Architecture, Challenges, and Lessons

Overview

The JD.com evaluation and share system collects product ratings, textual comments, and user‑uploaded images or videos, providing a unified API for all front‑end channels (PC, App, mobile web, WeChat, QQ, etc.). The architecture is built around a middleware layer, a base service that abstracts storage, a Solr‑based search engine, and Redis caching.

Core Architecture

Evaluation Middleware exposes read/write REST/GRPC interfaces. It receives evaluation submissions, forwards the payload to the Evaluation Base Service , and publishes an event to a message broker (e.g., Kafka) for asynchronous processing.

Evaluation Base Service isolates the middleware from the underlying databases. It supports three storage engines:

MySQL – relational tables for user‑evaluation mapping, product‑evaluation mapping, and reply relationships.

MongoDB – document store for comment bodies and media URL references.

HBase – column‑family store mirroring MongoDB data to provide high‑availability reads.

When an evaluation is created, the middleware writes the data via the base service and emits a message. Two subscriber services – Front‑end Search Service and Back‑end Search Service – consume the event and index the new record into a Solr cluster.

Search and Caching Layer

Solr serves as the enterprise search platform. The index is sharded by business dimension (e.g., product, service) and partitioned by time to improve query performance. Query patterns include:

GET /search?productId=12345&rating=good&mediaOnly=true

Redis caches the most frequently accessed result sets. The read flow is:

Front‑end service checks Redis for a cached key (e.g., eval:list:product:12345:page:1).

If a cache hit occurs, the cached IDs are returned; the service then fetches full evaluation details from MongoDB/HBase in batch.

On a miss, the service queries Solr, stores the resulting ID list in Redis with a TTL, and proceeds as above.

This pattern reduces Solr load and limits database round‑trips under high concurrency.

Management Backend and Monitoring

The evaluation management console provides auditors and merchandisers with multi‑dimensional Solr queries (time‑based partitions, source tags, media type). It also triggers reward‑bean issuance after order‑completion events by listening to the same message broker.

Monitoring components track:

Database (MySQL, MongoDB, HBase) storage usage and latency.

Redis hit‑rate and memory consumption.

Solr query latency, shard health, and index size.

Message‑broker throughput and consumer lag.

Alert thresholds are defined for each metric to enable proactive scaling.

Operational Tasks

Daily maintenance includes:

Data cleaning : run semantic scoring jobs on existing evaluations, promote high‑quality content, and demote or hide low‑value entries.

Filter condition updates : modify Solr query parameters (e.g., recent‑three‑months view) and adjust middleware logic accordingly.

Schema evolution : add new fields such as mediaType for video reviews, update base‑service DTOs, and propagate changes to Solr mappings.

AI‑driven tagging : ingest evaluation text into an NLP pipeline, generate semantic tags (e.g., “high screen clarity”), store tags in MongoDB, and expose them via API.

Exception handling & data governance : provide tools to recalculate evaluation aggregates, expand storage partitions, and clean near‑full tables.

Component‑Based Design Principles

Small‑and‑Beautiful

All database interactions are funneled through the base service, keeping MySQL, MongoDB, and HBase isolated from other modules. Redis and Solr are accessed directly by the modules that need them, with logical grouping and sharding to simplify operations.

Big‑and‑Full

Evaluation records carry source tags (e.g., recharge, second‑hand, 1‑shop) and content‑type tags (text, image, video). The middleware adds conditional logic for complex retrievals, while the management backend offers flexible query dimensions and reward‑qualification rules.

Deployment and Scalability

Modules are deployed in logical groups. Each group runs its own instance of the middleware and base service, pointing to dedicated database clusters. Redis and Solr are configured with group‑specific sharding keys, allowing independent scaling. Adding a new business line only requires provisioning a new group configuration and connecting it to the shared base service APIs.

Key References

Architecture diagrams (illustrative only):