The Evolution of Alipay’s Double 11 Technical Architecture: From Capacity Crises to Cloud‑Native Success

Since the first Double 11 in 2009, Alipay engineers have repeatedly faced the challenge of handling explosive transaction volumes, often starting with ad‑hoc capacity expansions and manual load‑testing that barely kept the system alive.

Early crises, such as the 2010 incident where the accounting database ran out of space within seconds, forced the team to make rapid, high‑risk decisions—cutting services and manually reallocating resources—to avoid downtime.

Learning from these emergencies, the team introduced systematic stress‑testing, built a prototype traffic‑shaping system called spanner , and began a multi‑year “architecture revolution” that emphasized modularization, dynamic scaling, and the migration from Oracle to the internally‑developed OceanBase distributed database.

By 2014, OceanBase proved its capability by handling 10 % of Double 11 traffic, and subsequent years saw continuous improvements: cloud‑native deployments, elastic capacity scheduling, and a shift toward automated, end‑to‑end performance platforms that reduced failure rates dramatically.

The narrative also highlights cultural practices—team rituals, morale‑boosting activities, and the belief that “nothing is impossible”—that helped sustain the relentless drive for higher throughput, culminating in a system that now processes tens of thousands of transactions per second with near‑zero incidents.