Designing Flash‑Sale (秒杀) Systems: Architecture, Challenges, and Solutions

In the introduction the author, a senior architect, states that flash‑sale (秒杀) events generate massive, instantaneous traffic that must be handled without overselling and while keeping data consistency.

Flash‑Sale Scenarios

Typical examples include promotional sales like a one‑yuan Maotai purchase or a half‑yuan BMW grab, where millions of users compete for a limited number of items, often accompanied by a countdown timer.

Key Problems

1. Time synchronization : All clients must see the same countdown.

2. Bot / scalper prevention : Detect and block automated purchase attempts.

3. Backend capacity : The server must sustain the sudden surge of traffic.

Design Thinking for Flash‑Sale

The author argues that simply scaling hardware is unrealistic; instead a distributed approach is required.

Solution 1 – CDN Edge Services

Deploy lightweight services on CDN nodes to serve static assets and to collect the number of online users. The central data center receives periodic counts, enabling a probabilistic admission control based on a calculated probability (e). Users are routed to the data center only if they pass this probability check; others receive a “sale ended” response.

Solution 2 – Layered Filtering

Use CDN for static content, then perform authentication to filter bots, followed by load‑balancing (LVS + Keepalived) to distribute requests across an Nginx cluster. Additional rate‑limiting, service degradation, and caching layers are added to protect the database, with asynchronous order processing via a task queue.

Architecture diagrams (images) illustrate the flow from edge nodes to the central system.

Comparison with Other High‑Traffic Scenarios

The author compares flash‑sale handling with train‑ticket (12306) booking, noting that ticketing cannot pre‑filter users because the desired train is unknown until after queries, so batch releasing of tickets or a pre‑sale reservation system is recommended.

Conclusion

Flash‑sale systems rely on edge‑side traffic offloading, multi‑layer request filtering, and careful consistency management. For broader high‑concurrency events like Double‑11, a full‑scale distributed, elastic architecture with continuous performance testing and horizontal scaling is essential.