Evolution of Tmall Product Detail System Architecture: From Staticization to CDN‑Based Scaling

Author Xu Zhao (alias Chang Gong), a Java Web specialist at Alibaba, introduces the massive traffic challenges faced by Tmall’s browse‑type systems during Double‑11, where request volumes can exceed normal levels by dozens of times, requiring capacity planning, hardware expansion, and performance optimization.

The core architectural goal is to handle instantaneous peak loads at reasonable cost while ensuring scalability, stable response times, and high availability even when downstream services fail.

Since 2011, Tmall’s browse‑type systems have progressed through three major stages: staticization, unified web caching, and CDN staticization, each improving cache hit rates, traffic distribution, and system extensibility.

Stage 1 – System Staticization : The original thin‑front‑end architecture was enhanced by separating static and dynamic content, employing page‑level caching, and moving frequently accessed data to client‑side caches. Challenges included CPU‑intensive page rendering, limited Java‑side caching, and high expansion costs.

The solution introduced a four‑layer cache hierarchy (application, web server, CDN node, browser) using Alibaba’s distributed key/value store Tair, which offered superior I/O performance compared to local Nginx disk caches.

Cache invalidation combined proactive invalidation and automatic expiration. For product‑detail pages, changes triggered messages that queued IDs for invalidation via Tair, as illustrated in

.

Results: during Double‑11 2012, with an 80 % cache hit rate, QPS increased more than sevenfold while resource usage dropped to under 50 % of the previous level, and the static architecture mitigated hotspot attacks.

Stage 2 – Unified Web Cache : To overcome the limitations of per‑application caches, a shared cache layer was built, consolidating static‑content clusters, simplifying maintenance, and enabling global monitoring. The unified layer required a cache system supporting batch invalidation, ESI/CSI dynamic content filling, and high‑throughput networking (10 Gbps NICs).

The chosen solution integrated a custom Nginx variant (Tengine) with consistent‑hash routing, a centralized invalidation center, and a unified configuration pipeline, as shown in

.

Benefits included horizontal cache scaling, reduced per‑application cache costs, and improved resilience, though the cache layer introduced a new single‑point dependency.

Stage 3 – CDN Staticization : With the unified cache in place, static pages were pushed to CDN nodes, leveraging geographic distribution for lower latency and higher availability. Three technical challenges were addressed: CDN node invalidation (via active purge), maintaining high hit rates (controlled node deployment and consistent‑hash), and handling periodically changing dynamic fragments (using ESI and asynchronous APIs).

The final architecture (see

) combines CDN and the unified cache, with multi‑level caching, active/automatic invalidation, and ESI‑driven dynamic content filling.

Outcome: on Double‑11 2013, the CDN‑staticized system handled record PV and QPS levels with ample headroom, delivering stable performance, reduced latency, and a reusable blueprint for other large‑scale browse‑type services.