Designing High‑Concurrency Flash Sale (秒杀) Systems: Challenges and Solutions

Flash‑sale (秒杀) events like Alibaba's Double‑11 generate massive, short‑lived traffic spikes where millions of users compete for a limited number of items, putting extreme pressure on servers, networks, and databases.

Technical challenges include sudden server and bandwidth demand increases (3‑5× normal load), high QPS requirements (tens of thousands of requests per second), and the risk of system avalanche when a single node fails and traffic cascades to others.

Solution architecture starts with upstream request interception to reduce downstream pressure, employing rate limiting, static page delivery via CDN, duplicate‑submission prevention, and user‑level throttling (e.g., IP limits).

On the backend, a gateway layer enforces UID access frequency limits, while the service layer buffers requests using message queues (RocketMQ, Kafka) and caches (Redis) to smooth peaks. Requests are first placed into a queue (e.g., RPUSH key value ) and later consumed by worker threads that pop successful IDs ( LPOP key ) and finalize orders in the database.

Read‑heavy operations leverage Redis to offload database reads, and write‑heavy operations can also be performed in Redis with periodic synchronization to the persistent store.

The database layer remains protected by upstream filtering, handling only the capacity‑bounded traffic that passes the queue and cache layers.

Design summary emphasizes five principles: rate limiting to admit only a fraction of traffic, throttling (peak‑shaving) using caches and message queues, asynchronous processing, in‑memory caching to avoid disk I/O bottlenecks, and horizontal scalability to add resources during peak periods.