How to Tackle 50k QPS Flash Sales: Backend Strategies for Extreme Concurrency

1. Challenges of Large‑Scale Concurrency

In a past project I faced a 50,000‑requests‑per‑second flash‑sale scenario, which exposed many problems if the web system is not specially optimized. The static HTML can be served via CDN, but the real bottleneck lies in the backend API that must respond extremely quickly, preferably using in‑memory storage like Redis instead of direct MySQL access, and employing asynchronous writes for complex business logic.

When the system cannot keep up, average response time rises, leading to a drop in effective QPS. For example, with 20 Apache servers each configured for 500 MaxClients and a 100 ms response time, the theoretical peak is 100,000 QPS, but under load the response time may increase to 250 ms, reducing capacity to 40,000 QPS and causing a “traffic jam” where requests exceed available connections.

Overload protection should be applied at the entry layer, rejecting excess traffic before it reaches the application, rather than relying on front‑end tricks that users may dislike.

2. Cheating Techniques: Attack and Defense

Attackers use tools to send massive requests from a single account, multiple accounts, or rotating IPs, undermining fairness and potentially bypassing simple logic checks. For a single‑account flood, limiting each account to one concurrent request and using Redis with a watch‑based optimistic lock can block excess attempts.

When many accounts are created ("zombie accounts"), IP‑rate limiting, captchas, or outright IP bans can mitigate abuse, though false positives are possible. Rotating IP attacks are harder to detect; practical defenses include raising business thresholds and mining account behavior data to filter suspicious patterns.

Ticket‑scalping illustrates the same problem: automated scripts, human‑in‑the‑loop captcha solving, and account swapping enable scalpers to dominate limited inventory.

3. Data Safety under High Concurrency

Concurrent writes can cause overselling when multiple requests read the same remaining stock (e.g., 99 items left) and all succeed, resulting in more sales than inventory. Traditional pessimistic locks serialize access but dramatically increase latency under high load.

A FIFO queue can avoid lock starvation but may exhaust memory when request bursts exceed processing speed. Optimistic locking, using version numbers or Redis watch, allows all requests to attempt updates while only those with matching versions succeed, offering a balanced solution for flash‑sale scenarios.

4. Summary

As internet usage grows, high‑concurrency situations like e‑commerce flash sales become common. Although specific technical solutions vary, the underlying challenges—interface speed, overload protection, cheating mitigation, and data consistency—are similar, allowing engineers to apply a shared set of strategies across different domains.