Mastering High‑Concurrency Flash Sales: Preventing System Collapse

1. Challenges of Large‑Scale Concurrency

Activities like the Spring Festival Gala or e‑commerce flash‑sale events generate billions of interactions, putting unprecedented pressure on web systems. When a service receives tens of thousands of requests per second, both optimization and stability become critical.

2. Reasonable Design of Request Interfaces

A flash‑sale page typically has two parts: static HTML (served via CDN) and a backend API that must handle high QPS and return results as quickly as possible. Using in‑memory storage such as Redis for the critical path and avoiding direct MySQL writes—preferring asynchronous persistence—greatly reduces latency.

3. High‑Concurrency Must Be Fast

Throughput is measured by QPS. Assuming a 100 ms response time, 20 Apache servers each with MaxClients = 500 yield a theoretical 100 000 QPS, but real‑world load increases response time, reducing effective QPS dramatically. For example, a rise to 250 ms cuts capacity to about 40 000 QPS, leaving a gap that causes request queuing and “traffic jams.”

4. Restart and Overload Protection

Blindly restarting a saturated system often fails; it is better to reject traffic at the entry layer, pre‑heat dependent services (e.g., Redis), and then restart. Overload protection can be implemented by rejecting excess requests early, though front‑end filtering is user‑unfriendly; placing protection at the CGI/NGINX layer is preferable.

5. Attack and Defense

5.1 Single Account, Multiple Requests – Users may fire hundreds of requests from a browser plugin, breaking fairness. A simple mitigation is to allow only one successful request per account, using Redis with a watch‑based optimistic lock.

5.2 Multiple Accounts, Bulk Requests – “Zombie” accounts created en masse can be throttled by detecting high request rates from a single IP, applying captchas, or outright blocking the IP.

5.3 Multiple Accounts, Rotating IPs – Attackers may use proxy pools or compromised machines to rotate IPs, making IP‑based blocking ineffective; raising participation thresholds (e.g., account level) and data‑mining for abnormal behavior become necessary.

5.4 Train‑Ticket抢购 – Yellow‑cabs use multiple accounts and real‑person captcha solving services to bypass verification, making the problem hard to solve without stricter business rules or behavioral analytics.

6. Data Safety Under High Concurrency

Concurrent writes can cause thread‑safety issues and “over‑issuance” where more items are sold than available. Example: when only one item remains, several concurrent requests may all see the same stock and all succeed.

6.1 Over‑Issuance Causes – Lack of atomic stock checks leads to duplicate sales.

6.2 Pessimistic Lock – Lock the data during modification; however, in high‑traffic scenarios many requests may starve, increasing latency and exhausting connections.

6.3 FIFO Queue – Serialize requests in a first‑in‑first‑out queue to avoid starvation, but the queue can overflow under extreme load, still causing latency spikes.

6.4 Optimistic Lock – Use version numbers (e.g., Redis WATCH) so only the request with the correct version updates the stock; others fail gracefully, offering a balanced solution for high concurrency.

7. Conclusion

High‑concurrency flash‑sale scenarios are common as internet usage grows. Although specific technologies differ, the core challenges—request bottlenecks, overload protection, abuse mitigation, and data consistency—are similar, allowing shared solution patterns across systems.

Source: Nginx