How JD.com Scaled Its Product Detail Page to Tens of Billions of Requests

During Double 11, JD.com’s product detail page handled tens of billions of requests without downtime by introducing a unified service architecture that consolidates promotion, inventory, recommendation, and other functions behind a single Nginx+Lua entry point, employing multi‑level caching, service isolation, and flexible degradation mechanisms.

21CTO
21CTO
21CTO
How JD.com Scaled Its Product Detail Page to Tens of Billions of Requests

Why a Unified Service Is Needed

The product detail page depends on many services; a single unified entry simplifies management, enables centralized monitoring, allows graceful degradation, reduces asynchronous requests, and moves business logic to the backend.

Overall Architecture

All requests first hit Nginx, which runs Lua for pre‑processing. If the request is invalid, it is rejected immediately. Otherwise, Nginx checks a local cache; on a hit, data is returned. If missed, a distributed Redis cluster is queried; a hit returns data. If still missed, Nginx forwards the request to Tomcat, writes the result asynchronously back to Redis, and returns the response.

The Redis cluster is deployed across data‑center rooms; data is written to a primary cluster and replicated to others, ensuring consistency without separate clusters per room.

Key Architectural Ideas and Summary

Two read‑service patterns

Local cache

Multi‑level cache

Unified entry / service closed‑loop

Access‑layer introduction

Frontend logic moved to backend

Frontend interface aggregation on server side

Service isolation

Two Read‑Service Patterns

1. Distributed Redis Read

Redis is deployed separately from Nginx; cross‑machine reads are possible but cross‑data‑center reads are avoided thanks to master‑slave replication. Suitable when performance requirements are moderate.

2. Local Redis Read

Nginx and Redis run on the same machine, eliminating cross‑machine/network latency. If the local Redis miss, the request falls back to Tomcat. This mode may be limited by TCP connections; using Unix domain sockets can mitigate the issue.

Local Cache

Nginx uses its shared dictionary (via HttpLuaModule) as a local in‑memory cache that survives reloads. Consistent hashing is used for load balancing and URL rewriting to improve hit rates.

Dimension‑based caching stores data such as merchant info, shop info, ratings, brand, and category. A 30‑minute local cache reduced request volume by roughly threefold.

Multi‑Level Cache

The unified service employs four cache layers:

Access‑layer local cache in Nginx for hot‑spot protection.

Distributed Redis clusters per data‑center for large‑scale discrete data.

Tomcat’s local heap cache for frequently accessed small data (e.g., categories, brands).

Main Redis cluster as a safety net when all upper layers miss, protecting backend services from traffic spikes.

Unified Entry / Service Closed‑Loop

All core interfaces of the product detail page are routed through the unified service, either by querying databases/caches with business logic or by simple proxying and monitoring.

Introducing the Nginx Access Layer

The access layer performs pre‑validation, caching, business‑logic handling, degradation switches, AB testing, gray releases, monitoring, and rate limiting.

Data validation/filtering before forwarding to backend.

Cache pre‑position using Nginx shared dict and Lua.

Business logic moved to Lua for fast, zero‑downtime updates.

Granular degradation switches (global vs. atomic, access‑layer vs. backend).

AB testing via Lua‑controlled upstream selection.

Gray release/traffic switching through configurable upstream groups.

Monitoring of status, request_time, response_time.

Rate limiting per IP or per logged‑in user; optional request sleeping.

Frontend Business Logic Post‑Position

Frontend JavaScript is kept thin; most logic is performed on the server so that updates can be deployed in seconds without CDN cache delays.

Frontend Interface Server Aggregation

Multiple backend services (e.g., promotion, inventory, recommendation) are aggregated in the access layer using Lua coroutines, exposing a single API to the frontend. Example: a single request to

http://c.3.cn/recommend?methods=accessories,suit,combination&sku=1159330&cat=6728,6740,12408&lid=1&lim=6

returns combined recommendation data.

Service Isolation

Isolation is achieved through thread‑pool segregation (Servlet 3 async), deployment/group segregation, and splitting high‑traffic services into separate applications.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

BackendScalabilitycachingService Architecturehigh-traffic
21CTO
Written by

21CTO

21CTO (21CTO.com) offers developers community, training, and services, making it your go‑to learning and service platform.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.