Evolution of JD Daojia Product System Architecture: From Simple 1.0 Design to Domain‑Driven 3.0

The JD Daojia product system is a core component of the e‑commerce platform, providing stable, high‑performance product data to numerous downstream services such as home pages, stores, carts, orders, settlement, after‑sale, inventory, and pricing.

Version 1.0 adopted a simple, all‑in‑one design to support rapid business iteration, but the tight coupling of B‑side and C‑side services caused resource waste, performance volatility, cache breakdown under high concurrency, and insufficient monitoring.

Version 2.0 introduced high‑availability improvements: an AP + eventual consistency model with a distributed Redis cluster, separation of B‑side and C‑side services, active‑active multi‑region deployment, Sentinel‑based flow control, and a comprehensive monitoring platform.

Specifically, the AP principle allowed temporary read‑write inconsistencies acceptable for the C‑side, while Redis clusters boosted read availability; independent B/C services prevented write spikes from degrading read stability; multi‑active data centers and dual‑rack Redis/MongoDB replication ensured resilience; Sentinel limited non‑core traffic during traffic spikes.

Version 2.0 also addressed performance: the C‑side removed MongoDB fallback queries, persisted Redis KV to eliminate expiration‑related cache misses, introduced asynchronous tasks to keep Redis and MongoDB consistent, and added an ehcache in‑memory layer to handle hot dictionary keys.

These changes dramatically reduced latency, eliminated cache penetration, and improved overall throughput, especially during large‑scale promotional events.

Version 3.0 focuses on domain‑driven construction: a top‑down logical layering isolates concerns, a bottom‑up method decomposition introduces Zookeeper switches for safe migration, and business domains are split into independent services (brand, attribute, category, info, image, etc.). Redis caches are also partitioned into dedicated clusters for main info, details, and attributes.

Microservice evolution follows the domain split, deploying separate services for main information, images, text, and attributes, each with dedicated resources, thereby improving availability, scalability, and fault isolation.

Looking ahead, the system aims to integrate AI and algorithmic capabilities for intelligent product governance, automated data collection, validation, and rapid product entry, further enhancing the platform's competitiveness.

In summary, each architectural iteration—1.0 for rapid iteration, 2.0 for stability and high‑availability, 3.0 for systematic domain construction—adheres to the principle of "appropriate and simple" design, ensuring continuous, business‑aligned evolution.