Scaling Tmall’s Double‑11 Pages: From Staticization to CDN Architecture

During Tmall’s Double‑11 shopping festivals, product‑detail and shop pages face traffic that can be dozens of times higher than normal, requiring capacity planning, hardware scaling, and performance optimization.

The architectural goal is to handle sudden peak requests at reasonable cost while ensuring scalability, stable response times, and high availability even when external dependencies fail.

Evolution

Since 2011, Tmall’s browsing systems have progressively adopted static‑generation techniques to separate static and dynamic content, cache static pages, and load dynamic data asynchronously.

The evolution includes three stages: single‑machine staticization, unified cache integration, and full CDN deployment (see Figure 1).

Stage 1: System Staticization

Early Tmall browsing systems used thin front‑end applications with client‑side caching and page‑cache to reduce backend pressure. Challenges included CPU‑heavy page rendering, limited Java‑side caching, linear scaling costs, and inability to meet burst traffic.

Application server bottlenecks due to heavy CPU usage for page rendering.

Java‑side caching already saturated, leaving little performance headroom.

Horizontal scaling only provided linear capacity increase, leading to high expansion costs.

Key architectural changes focused on:

Caching full HTTP responses.

Moving cache to the web server layer, bypassing business logic.

Ensuring large, non‑single‑point cache space that is easy to maintain.

Stage 2: Unified Web Cache

After successful staticization of product‑detail pages, other browsing services adopted similar patterns. To reduce cost and improve stability, a unified web‑cache layer was introduced, sharing a static‑page cluster across services.

Benefits of the unified layer include reduced per‑application cache maintenance, centralized monitoring, automated configuration, and dynamic memory sharing to handle attacks.

Technical requirements for the unified layer:

Support ESI parsing and GZIP compression.

Handle Double‑11/Double‑12 QPS demands.

Provide batch invalidation, long‑connection support, and programmable HTTP‑header configuration.

Stage 3: CDN Staticization

With a unified cache in place, static pages could be pushed to CDN nodes, bringing content closer to users and further mitigating peak traffic and attack risks.

CDN staticization addressed three main challenges:

Distributed node invalidation – solved via active invalidation requests propagated from a central invalidation center.

Cache hit rate – improved by controlled node deployment, consistent hashing, and regional traffic concentration.

Dynamic content timing – handled by asynchronous API calls for price/stock and ESI includes for periodic page module updates.

The final architecture combines application servers, a multi‑level cache (browser → CDN → unified cache → application), unified invalidation mechanisms, and ESI/CSI for dynamic fragment filling.

Results: In Double‑11 2012, staticization raised safe QPS by over 7× with less than 50 % of the original resource usage; in 2013, the CDN‑enabled architecture handled record‑breaking PV and QPS levels with ample headroom, demonstrating high availability, cost‑effective scalability, and a reusable cache/invalidation framework for future browsing systems.