How Tmall Scaled Its Product Detail Pages for Double‑11: From Staticization to CDN‑Powered Architecture

Background

During Tmall’s Double‑11 events, browsing systems such as product‑detail pages face traffic spikes many times higher than normal, requiring scalable capacity, stable response times, and high availability even when dependent services fail.

Evolution

Since 2011, Tmall has progressively applied staticization techniques to separate dynamic and static content, cache static content, and load dynamic data asynchronously. The evolution passed three stages: single‑machine staticization, unified cache integration, and full CDN‑based delivery (see Figure 1).

Stage 1: System Staticization

Early systems used thin front‑end applications with page‑cache and client‑side caching, but faced CPU bottlenecks, limited Java‑side caching, and costly horizontal scaling. The solution was to cache full HTTP responses, move caching to the web server, and ensure large, non‑single‑point cache space.

Static‑Content Separation

Pages were divided into low‑frequency, public parts (e.g., product title, description) stored as static HTML, while time‑sensitive data (price, inventory) are filled asynchronously via CSI.

Cache Hierarchy

A four‑layer cache was built: application‑server cache, web‑server cache, CDN nodes, and browser cache (see Figure 3). Tair, Alibaba’s distributed key/value store, was chosen for its low latency and stable performance.

Cache Invalidation

Both proactive invalidation (triggered by business events) and automatic expiration are used. For product‑detail pages, changes to product data or shop decoration send messages to an invalidation service, which calls the local Tair interface to purge the relevant keys (see Figure 4).

Stage 2: Unified Web Cache

After the first stage proved effective, other browsing services adopted the same staticization pattern. To overcome single‑machine cache limits, a centralized web‑cache layer was introduced, sharing memory across services, simplifying monitoring, and enabling batch invalidation.

Cache System Choice

The unified layer needed to support ESI/CSI dynamic content, high QPS, batch invalidation, long connections, and programmable HTTP headers. The selected solution provides fast invalidation, pre‑warming, CSS/JS merging, and consistent hashing.

Unified Invalidation Mechanism

A global invalidation center receives purge requests and distributes them to cache nodes, ensuring timely removal of stale objects (see Figure 5).

Web Server Refactoring

Alibaba developed a customized Nginx variant (Tengine) to provide consistent‑hash grouping, session integration, and virtual‑host support.

Network Support

10‑GbE NICs and careful egress capacity planning eliminated network bottlenecks for both cache hits and miss‑origin traffic.

Overall Deployment

The deployment combines front‑end Nginx, the cache system, and backend Java services, with unified cache supporting ESI/CSI, and a centralized invalidation center (see Figure 6).

Stage 3: CDN Staticization

With the unified cache in place, static pages could be pushed to CDN nodes, providing geographic proximity, higher capacity, and stronger protection against attacks.

CDN Technical Challenges

Distributed node invalidation – solved by proactive purge requests.

Cache hit rate – improved by controlled node deployment and consistent‑hash rules.

Dynamic content timing – handled by asynchronous APIs for price/stock and ESI for timed banners.

Final Architecture

The complete architecture integrates multi‑layer caching, proactive and automatic invalidation, and dynamic content filling via ESI/CSI (see Figure 7).

Results

During Double‑11 2013, the CDN‑static architecture delivered record‑high page views and QPS with stable performance, low latency, and ample headroom for future traffic growth, while simplifying maintenance and reducing costs.