How Tmall Scaled Its Product Pages for Double‑11: CDN‑Driven Staticization Blueprint

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 external dependencies fail.

Evolution

Since 2011, Tmall has progressively adopted staticization to separate dynamic and static content, cache static pages, and load dynamic data asynchronously. The evolution passed three phases: single‑machine staticization, unified caching, and full CDN staticization.

The current CDN‑based static architecture offers high availability and elastic scaling, featuring:

Dynamic‑static separation: HTML staticization and hotspot isolation.

Distributed cache system using CDN nodes.

Multi‑level cache: two CDN layers plus an application layer.

Unified static service cluster.

Consistency maintenance with active and automatic cache invalidation.

Dynamic content filling supporting various freshness requirements.

Real‑time monitoring and alerting for traffic, invalidation, hit rate, etc.

Stage 1: System Staticization

Early browsing systems relied on thin front‑end applications and page caches, but faced CPU bottlenecks, limited Java‑side caching, and costly horizontal scaling. The solution was to cache HTTP responses, move caching to the web server, and ensure ample, non‑single‑point cache space.

From 2012, a staticization project separated static and dynamic parts, caching static content while filling dynamic sections via CSI. The architecture introduced three cache layers—application server, web server, CDN node, and browser.

Cache Invalidation

Invalidation combines proactive backend invalidation and automatic expiration. Proactive invalidation monitors data sources (e.g., product updates), processes large volumes of invalidations per second, and supports batch or single‑item invalidation.

Stage 2: Unified Web Cache

After successful staticization, multiple browsing services adopted a shared cache cluster to reduce costs, improve stability, and increase hit rates. The unified layer required a cache system supporting ESI/CSI, high QPS, batch invalidation, long connections, and programmable HTTP headers.

Alibaba’s custom Nginx (Tengine) was deployed as the web server, with 10 Gbps NICs to eliminate network bottlenecks.

Stage 3: CDN Staticization

The unified cache removed single‑machine memory limits, enabling full CDN deployment. Three technical challenges were addressed: CDN node invalidation (active invalidation with a validation layer), hit‑rate optimization (controlled node placement and consistent hashing), and regional dynamic content timing (dynamic data via APIs, ESI for timed page fragments).

Overall Architecture

The final architecture combines a unified cache layer, CDN nodes, and web servers capable of distinguishing CDN‑origin requests from normal traffic, supporting ESI/CSI for dynamic content, and providing robust cache invalidation.

Performance results showed a 7‑fold increase in safe QPS during Double‑11 2012 with less than half the resources, elimination of hotspot attacks, and a weak dependency on backend Java services, enabling continued service even when backends were unavailable.

By Double‑11 2013, the CDN‑staticized system handled record PV and QPS levels with ample headroom, demonstrating that the architecture can be replicated for other browsing services to achieve high stability and scalability.