How to Build Scalable Flash Sale Systems: Tackling High‑Concurrency Challenges

1. Challenges of Massive Concurrency

When a web system receives tens of thousands of requests per second during a flash‑sale or ticket‑buying event, it can quickly become unstable if not properly optimized.

Typical bottlenecks lie in the backend API rather than static HTML, which is usually served by a CDN. The API must respond extremely fast, often requiring in‑memory data stores like Redis and asynchronous writes instead of direct MySQL access.

High QPS (queries per second) puts pressure on server resources. For example, 20 Apache servers each with MaxClients=500 and an average response time of 100 ms theoretically yield 100 000 QPS, but real‑world latency and CPU context‑switch overhead reduce this dramatically.

When response time grows to 250 ms under 50 k QPS, effective throughput drops to 40 k QPS, creating a “traffic jam” where incoming requests exceed available connections, leading to cascading failures and a system “avalanche.”

2. Overload Protection and Restart Strategies

Blindly restarting a crashed service often fails; it is better to reject traffic at the entry point, pre‑warm dependent services like Redis, and apply graceful restarts.

Overload protection can be implemented at the CGI layer to quickly return a failure response, rather than relying on front‑end filters that users dislike.

3. Cheating Tactics and Countermeasures

Attackers use multiple requests from a single account, mass‑registered “zombie” accounts, or rotating IP proxies to flood the system.

Single‑account flood: Limit each account to one concurrent request using a Redis flag with a WATCH‑based optimistic lock.

Multiple accounts: Detect high request rates from a single IP and present CAPTCHAs or block the IP.

Rotating IPs: Since malicious traffic can mimic legitimate users, raise participation thresholds (e.g., account level) and employ behavior‑based data mining to filter out suspicious accounts.

4. Ticket‑Buying (12306) Specific Issues

Ticket scalpers exploit multi‑account strategies and human‑in‑the‑loop CAPTCHA solving, making automated defenses difficult; data‑mining of account activity remains the most viable mitigation.

5. Data Safety Under High Concurrency

Concurrent writes can cause “overselling” when multiple requests read the same remaining stock and all succeed.

Optimistic lock: Use version numbers or Redis WATCH to allow only one successful update.

Pessimistic lock: Lock the resource during update, but this can cause long wait times under heavy load.

FIFO queue: Queue requests in order, though the queue may overflow if arrival rate exceeds processing speed.

Optimistic lock with Redis: Provides a balanced solution with acceptable CPU overhead.

Conclusion

Flash‑sale and ticket‑buying spikes are classic high‑concurrency scenarios. While specific technologies differ, the core challenges—request design, overload protection, anti‑cheat measures, and safe data handling—are common, and the presented strategies can be adapted to many backend systems.