How to Tackle 50k QPS Flash Sale: Backend Design, Overload Protection, and Anti‑Cheat Strategies

1. Challenges of Large‑Scale Concurrency

In a previous project I faced a 50 k QPS flash‑sale spike, which exposed many problems in the web system. Without targeted optimizations the system quickly falls into abnormal states, so I discuss the optimization ideas and methods.

1.1 Reasonable Design of Request Interfaces

A flash‑sale page consists of two parts: static HTML (served by CDN) and the backend API that processes the purchase. The static part is low‑pressure, while the real bottleneck lies in the backend API, which must handle high concurrency and respond as fast as possible. Using in‑memory storage (e.g., Redis) for the critical path is preferable to direct MySQL access, and asynchronous writes are recommended for complex business logic.

Some systems use “delayed feedback,” where the result is shown later; this harms user experience and appears opaque.

1.2 The Need for Speed in High Concurrency

Throughput is measured by QPS (queries per second). Assuming 100 ms average response time, 20 Apache servers each with MaxClients = 500 yield a theoretical peak of 100 k QPS (20 × 500 / 0.1). In reality, high load increases response time, reducing effective QPS. For example, if response time grows to 250 ms, the peak drops to 40 k QPS, leaving a shortfall of 10 k QPS for a 50 k target.

When the system cannot serve all requests, a “traffic jam” occurs, similar to a highway lane reduction, leading to connection exhaustion and potential cascade failures (the avalanche effect).

1.3 Restart and Overload Protection

During an avalanche, blindly restarting services often fails; it is better to reject traffic at the entry layer before restarting. Services like Redis or Memcached also need warm‑up time. Overload protection should be placed at the CGI entry point to quickly return a failure response, rather than relying on front‑end filtering that users may criticize.

2. Cheating Techniques: Attack and Defense

Flash‑sale spikes attract massive request traffic, including many illegitimate requests from bots and scripts. Attackers use tools to send thousands of requests per account or create large numbers of “zombie” accounts.

2.1 Multiple Requests from a Single Account

Limiting each account to a single concurrent request, enforced via a Redis flag with optimistic locking, prevents this abuse. Alternatively, queue the requests per account.

2.2 Multiple Accounts Sending Requests Simultaneously

Detect high request rates from a single IP and either present a CAPTCHA or block the IP. This approach is simple but may affect legitimate users sharing the same IP.

2.3 Distributed IP Attacks

Attackers rotate IPs using proxy pools or compromised machines, making detection difficult. The practical defense is to raise business thresholds (e.g., account level requirements) and apply data‑mining to identify suspicious accounts.

2.4 Ticket‑Scalping Example

Scalpers use multiple accounts and human‑in‑the‑loop CAPTCHA solving to bypass protections; no perfect solution exists beyond profiling and filtering suspicious behavior.

3. Data Safety Under High Concurrency

Concurrent writes can cause thread‑safety issues. MySQL locks are not suitable for massive spikes. Over‑selling (overselling) occurs when multiple requests read the same remaining stock and all succeed.

3.1 Causes of Overselling

When only one item remains, simultaneous reads see the same stock and all pass the check, leading to excess sales.

3.2 Pessimistic Locking

Pessimistic locks serialize updates, but under high load many threads wait indefinitely, increasing response time and exhausting connections.

3.3 FIFO Queue Approach

Placing requests in a first‑in‑first‑out queue avoids lock starvation but can overflow memory under extreme traffic, still causing performance degradation.

3.4 Optimistic Locking

Optimistic locking uses version numbers; only the request with the correct version updates successfully, others receive a failure response. Redis’s WATCH command provides this capability with acceptable CPU overhead.

4. Summary

As internet usage grows, high‑concurrency scenarios become common. Flash‑sale and ticket‑scalping are typical examples. Although specific technical solutions vary, the challenges are similar, and the problem‑solving mindset is largely shared.

Source: PHP Daily