How to Survive Flash‑Sale Traffic: Backend Strategies for 100k QPS

1. Large‑scale concurrency challenges

Flash‑sale and ticket‑buying spikes can generate tens of thousands of requests per second, testing a web system's stability and performance. Without targeted optimizations, the system quickly becomes unstable.

1.1 Reasonable request interface design

A flash‑sale page consists of static HTML (served via CDN) and a backend API that must handle high concurrency and respond as quickly as possible. Using in‑memory storage such as Redis and avoiding direct MySQL writes, or employing asynchronous writes, improves response speed.

1.2 “Lagged feedback” pitfalls

Some systems hide the result of a flash‑sale and reveal it later, which harms user experience and appears manipulative.

2. High concurrency demands speed

Throughput is measured by QPS. For example, 20 Apache servers each with MaxClients=500 and an average response time of 100 ms yield a theoretical 100 000 QPS, but real‑world load increases response time, reducing effective QPS.

When response time grows to 250 ms, the same setup only achieves 40 000 QPS, leaving a shortfall for a 50 000 QPS flash‑sale and causing request queuing and “avalanche” failures.

2.1 Overload protection and restart

Blindly restarting a crashed service can worsen the avalanche. Instead, reject traffic at the entry point, pre‑warm services like Redis, and implement graceful restarts.

3. Cheating tactics: attack and defense

3.1 Single account flooding

Users may send hundreds of requests from one account, bypassing simple checks and causing race‑condition bugs where multiple requests see an empty purchase record.

Solution: allow only one request per account at the entry point, using Redis with a lock (e.g., WATCH) to enforce exclusivity.

3.2 Multiple accounts flooding

Attackers register thousands of “zombie” accounts and use them to flood the system. Rate‑limit per IP, present CAPTCHAs, or block abusive IPs, while balancing false positives.

3.3 Distributed IP attacks

Attackers rotate IPs using proxy pools or compromised machines, making detection hard. Mitigation relies on higher business thresholds and behavioral data mining to filter suspicious accounts.

3.4 Train ticket scalping

Scalpers use multiple accounts and human‑in‑the‑loop CAPTCHA solving to bypass verification, and even transfer tickets after purchase. No perfect technical solution exists; data‑mining of account behavior is the primary defense.

4. Data safety under high concurrency

4.1 Over‑selling causes

When inventory is low, concurrent reads may all see the same remaining stock and all succeed, leading to overselling.

4.2 Locking strategies

Traditional pessimistic locks serialize updates but can cause massive latency under high QPS. FIFO queues avoid starvation but can overflow memory. Optimistic locks (e.g., Redis WATCH with version numbers) provide a balanced solution.

Conclusion

Flash‑sale and ticket‑buying are typical high‑concurrency scenarios. While specific implementations differ, the challenges—request design, speed, overload protection, anti‑cheat measures, and data consistency—are common, allowing shared solution patterns across systems.

Source: compiled from various online resources