Alibaba Flash‑Sale Engine: Isolation, Static‑Dynamic Split & Real‑Time Hotspot Control

Background and Motivation

Alibaba’s flash‑sale (秒杀) system originated from a timed product listing feature on Taobao. When sellers heavily discounted items, the sudden traffic overwhelmed the detail page service, prompting the creation of a dedicated flash‑sale system to isolate and handle this burst of requests.

Hotspot Isolation

The first design principle is to isolate the 1% of hotspot requests so they do not affect the remaining 99% of traffic. Isolation is applied on three levels:

Business isolation : Sellers must register for the flash‑sale event, making the participating items known in advance for pre‑warming.

System isolation : Separate deployment groups and a dedicated domain name route flash‑sale traffic to distinct clusters.

Data isolation : Hot data is stored in dedicated cache clusters or MySQL instances, preventing a tiny fraction of data from impacting the majority.

Static‑Dynamic Separation (动静分离)

Static resources are cached on the client browser or CDN, while only the dynamic “refresh‑抢宝” button triggers a minimal request to the server. This reduces effective requests to about 10% of the total traffic and improves performance by more than threefold compared with a fully dynamic page.

Time‑Slice Throttling (基于时间分片削峰)

Introducing a quiz before ordering spreads the order‑placement peak from sub‑second to a 2‑10 second window, reducing the effective write‑TPS and limiting the impact of automated purchase bots. Similar mechanisms are used by Alipay’s “咻一咻” and WeChat’s “摇一摇”.

Layered Data Validation (数据分层校验)

Requests pass through a funnel‑style validation pipeline:

Static‑dynamic split at the front‑end.

Cache 90% of data in the browser.

Cache dynamic read data at the web layer.

Relax strong consistency for read‑only data.

Apply time‑based sharding for write operations.

Rate‑limit write requests.

Enforce strong consistency on writes (e.g., inventory cannot become negative).

Real‑Time Hotspot Discovery

The system builds an asynchronous collector that gathers hotspot keys from middleware such as Tengine, Tair, and HSF. A hotspot service publishes these keys, allowing downstream services (e.g., transaction service) to receive early warnings and apply protective measures within three seconds.

Key Technical Optimizations

Java concurrency handling : Use plain Servlets instead of heavyweight MVC frameworks, write directly to ServletOutputStream, and prefer JSON responses to reduce serialization overhead.

LocalCache for hot items : Cache immutable product metadata on each flash‑sale node before the event, and cache mutable inventory with a short passive expiration (a few seconds) that falls back to Tair on miss.

Database row‑lock mitigation :

Application‑level queuing per product to limit concurrent DB connections.

Database‑level global queuing using an InnoDB patch developed by Alibaba’s MySQL team, allowing serialized access to a single row.

Additional MySQL patches (COMMIT_ON_SUCCESS, ROLLBACK_ON_FAIL) reduce transaction latency to ~0.7 ms.

General Hotspot Principles for Large Promotions

From years of experience with flash‑sale systems, the following universal principles emerge: isolate hotspots, perform static‑dynamic separation, and apply layered validation across the entire request chain. Complementary measures such as rate limiting, local client caches, and dynamic data migration further protect against cache‑stampede and database overload.

Additional hotspot scenarios include:

Access hotspots in detail pages that can saturate cache servers; mitigate with client‑side LocalCache.

Update hotspots (e.g., frequent lastModifyTime changes) that benefit from SQL batching or automatic migration to dedicated hot‑data stores.

Index‑driven hotspots in search systems that require data sharding and additional dimensions to keep index size manageable.