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

In Tmall's Double‑11 events, browsing systems such as product detail and shop pages endure traffic surges many times higher than everyday loads, requiring capacity assessment, hardware scaling, and performance optimization. The architectural goal is to handle peak requests cost‑effectively while ensuring scalability, stable response times, and high availability, also addressing security, flow control, and disaster recovery.

Evolution Overview

Since 2011, Tmall's browsing systems have progressed through three major CDN‑based staticization stages: single‑machine staticization, unified web cache, and full CDN staticization, each improving cache hit rates, traffic distribution, system scaling, and user response speed.

Phase 1: System Staticization

The early architecture 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 separate static and dynamic content, cache static HTML, and fill dynamic parts asynchronously (CSI). This involved three steps: single‑machine staticization, unified cache integration, and complete CDN adoption.

Static‑dynamic separation: HTML staticization and hotspot separation.

Distributed cache system using CDN nodes.

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

Unified static service cluster.

Active and automatic cache invalidation mechanisms.

Support for various dynamic content fill strategies.

Real‑time monitoring of traffic, invalidation, and hit rates.

Phase 2: Unified Web Cache

After the first phase, multiple browsing services adopted similar staticization, revealing common issues such as single‑machine cache limits, insufficient hit rates, and high CSI integration costs. A unified web cache layer was introduced to share a staticization cluster, reduce maintenance costs, and improve monitoring.

The unified layer required a cache system supporting batch and single invalidations, ESI parsing, GZIP compression, and high QPS under Double‑11 load. Alibaba’s internal distributed key/value store Tair was chosen for its performance and low maintenance.

Application‑level cache reduces backend pressure.

Web‑server cache mitigates instant peaks and attacks.

CDN cache places content near users for faster response.

Browser cache lowers request volume and improves UX.

Cache invalidation combines proactive invalidation (triggered by data changes) and automatic expiration. A centralized invalidation center processes purge requests and propagates them to cache nodes.

Web servers were customized (Tengine, a Taobao‑tailored Nginx) to support consistent hashing, session frameworks, and virtual host configurations.

Network upgrades to 10 Gbps NICs eliminated bandwidth bottlenecks, and the deployment diagram shows front‑end Nginx, cache system, and backend Java services.

Phase 3: CDN Staticization

With a unified cache in place, the architecture moved to full CDN staticization, leveraging CDN’s distributed nodes for stronger capacity and attack resilience. Three technical challenges were addressed:

Node‑level cache invalidation via proactive purge requests.

Maintaining high hit rates by controlling node deployment and using consistent hashing.

Handling region‑specific dynamic content (price, inventory) through asynchronous APIs and ESI includes.

The final architecture combines static pages on CDN, a unified cache layer, and ESI/CSI for dynamic fragments.

Overall Architecture

Static pages are served from CDN; cache misses are fetched from the unified cache layer, which in turn may retrieve data from backend services. The system distinguishes CDN‑origin requests from normal traffic to avoid duplicate logging and compression.

Cache invalidation follows the same centralized process as in Phase 2, with tasks routed through an invalidation center to cache nodes.

Dynamic Content Filling

ESI tags are parsed by the cache layer, allowing partial page refreshes without full backend hits. Features include timed site‑wide changes via ESI Include, s‑maxage headers for controlled expiration, merged back‑origin requests to reduce load, and copy‑on‑write style updates to prevent request stalls.

Results

The CDN‑staticized architecture eliminated horizontal scaling limits of single‑machine caches, achieved higher hit rates, and supported Double‑11 traffic peaks with ample headroom. It provided high availability, reduced costs, and offered a reusable cache and invalidation framework for other Tmall browsing services.