Surviving 50k QPS Flash Sales: Backend Strategies for High‑Concurrency Seckill

1. Challenges of Massive Concurrency

Flash‑sale and ticket‑booking spikes generate tens of thousands of requests per second, testing the limits of any web system. Without targeted optimizations, the system can quickly become unstable.

1.1 Reasonable Design of Request Interfaces

A typical flash‑sale page consists of static HTML (served via CDN) and a backend API that must handle extremely high QPS. The API should be as fast as possible, preferably using in‑memory storage (e.g., Redis) and asynchronous writes instead of direct MySQL access.

Some systems use delayed feedback, showing results only after a short interval, which harms user experience and appears opaque.

1.2 The Need for Speed Under High Load

Throughput is measured by QPS. Assuming an average response time of 100 ms, 20 Apache servers each with MaxClients = 500 yield a theoretical peak of 100 000 QPS: 20*500/0.1 = 100000 In reality, CPU context switches, memory pressure, and network latency increase response time, reducing effective QPS. For example, if response time grows to 250 ms, the achievable QPS drops to 40 000:

20*500/0.25 = 40000

When the system cannot serve all incoming requests, a “snowball” effect occurs: overloaded servers fail, traffic shifts to remaining servers, and the whole service collapses.

1.3 Restart and Overload Protection

Blindly restarting a crashed service often leads to immediate failure. It is better to reject new traffic at the entry point, warm‑up dependent services (e.g., Redis), and only then restart.

2. Cheating Tactics: Attack and Defense

Attackers use bots, scripts, and large numbers of accounts to flood the API, increasing their chance of success. Defenses must counter these tactics.

2.1 Multiple Requests from a Single Account

Users may send hundreds of requests simultaneously via browser plugins. This can also expose race‑condition bugs where multiple requests read a “no‑record” state before any writes occur.

Solution: limit each account to a single in‑flight request using a Redis flag with an optimistic lock (WATCH).

2.2 Multiple Accounts Sending Requests Simultaneously

Mass‑registered “zombie” accounts are used to flood the system. Detecting high request rates from a single IP and presenting a CAPTCHA or blocking the IP can mitigate this, though care must be taken to avoid harming legitimate users sharing the same IP.

2.3 Distributed IP Attacks

Attackers rotate IPs using proxy pools or compromised machines, making IP‑based blocking ineffective. In such cases, raising business thresholds or applying behavior‑based data mining is necessary.

2.4 Ticket‑Purchasing Scams

Ticket scalpers employ multiple accounts and human‑in‑the‑loop CAPTCHA solving to bypass protections, making it extremely hard to block without affecting genuine users.

3. Data Safety Under High Concurrency

Concurrent writes can cause overselling. For example, when only one item remains, multiple requests may read the same stock value and all succeed, resulting in “over‑issue”.

3.1 Pessimistic Lock

Lock the row or item during the transaction so other requests wait. This guarantees correctness but can severely degrade performance under massive load.

3.2 FIFO Queue

Place incoming requests into a first‑in‑first‑out queue. While this avoids starvation, the queue can quickly exhaust memory if the arrival rate exceeds processing capacity.

3.3 Optimistic Lock

Use version numbers (or Redis WATCH) so that only the request with the correct version can commit; others receive a failure response. This reduces lock contention at the cost of extra CPU for version checks.

4. Summary

High‑concurrency flash‑sale and ticket‑booking scenarios are typical stress tests for modern web services. Although specific implementations differ, the core challenges—interface latency, overload protection, cheating mitigation, and data consistency—are shared, allowing common solution patterns across systems.