Unified Service Architecture for JD’s Billion-Scale Product Detail Page during Double Eleven

The article presents the design of a unified service platform that powers JD’s product detail page during the Double Eleven shopping festival, where traffic surged to tens of billions of requests without service disruption.

By consolidating various functionalities—promotion merging, inventory status, delivery, warranty, recommendation, and more—into a single gateway, the system gains centralized management, monitoring, and the ability to apply unified degradation and AB testing.

The overall flow starts with Nginx receiving the request, executing pre‑validation and Lua‑based logic, checking a local shared‑dictionary cache, then a distributed Redis cluster, and finally falling back to a Tomcat backend if caches miss. Results are asynchronously written back to Redis.

Two read‑service architectures are described: a distributed Redis‑only deployment and a local Redis deployment on the same machine as Nginx, each with trade‑offs in latency, cross‑machine traffic, and sharding requirements.

Local caching leverages Nginx’s shared dictionary and proxy cache to store hot data, while multi‑level caching adds a four‑tier hierarchy—Nginx local cache, regional Redis clusters, Java heap cache, and a primary Redis cluster—to minimize backend load and protect against cache‑miss storms.

The unified entry and service loop ensures data heterogeneity handling (e.g., inventory of bundled items) and closes the service loop by routing all core APIs through the platform.

An Nginx access layer implements pre‑validation, caching, business‑logic offloading, degradation switches, AB testing, gray‑release traffic routing, monitoring of request metrics, and rate limiting based on IP or user identity.

Front‑end logic is deliberately kept thin; most business rules are moved to the backend via Lua coroutines that concurrently invoke multiple services and aggregate responses, reducing the number of client‑side requests.

Service isolation is achieved through thread‑pool segregation, deployment/group isolation, and splitting high‑traffic services into separate applications, all monitored for health and performance.

The article also covers operational concerns such as timeout settings, retry policies, CDN versioning, and mechanisms to prevent overselling during flash‑sale events.

A Q&A section answers practical questions about backend pressure, high‑concurrency handling, cache consistency, authentication, and stock management strategies.