How This Architecture Handles Tens‑Fold Traffic Spikes Without Crashing

During major sales events, millions of users may simultaneously try to purchase a limited‑stock item, creating traffic spikes of 10‑100× the normal load. The core challenge is to avoid overselling, system crashes, and order loss.

The solution is organized into four distinct phases: reservation, waiting, purchase, and payment. Each phase presents unique problems—qualification distribution, read‑traffic flood, write‑traffic burst, and final data consistency.

Step 2 – Distributed Lock for Qualification : In the reservation phase, a Redis distributed lock is used. The command SET lock_key unique_value NX PX 10000 ensures only the first request succeeds (NX) and the lock expires after 10 seconds (PX) to avoid deadlocks. Unlocking is performed with a Lua script that verifies unique_value before deleting the key, guaranteeing atomicity. Production systems must run Redis in a multi‑node configuration (e.g., RedLock or ZooKeeper) to mitigate single‑node failures.

Step 3 – Double‑Layer Defense for the Waiting Phase : One minute before the flash‑sale countdown, users aggressively refresh the product page. The first defense is page static‑generation and CDN distribution, allowing users to fetch the page directly from edge nodes without hitting the backend. The second defense is server‑side rate limiting using Nginx’s ngx_http_limit_req_module with a token‑bucket algorithm; excess requests receive a “queueing” response, protecting downstream services.

Step 4 – MQ Peak Shaving and Inventory Protection : During the purchase phase, millions of order requests arrive simultaneously. All requests are first placed into a message queue; consumer workers pull at a controlled rate, smoothing the burst into a steady stream. Inventory is decremented atomically in Redis using DECR or a Lua script, ensuring no oversell. Only after a successful cache decrement is the order written asynchronously to the database.

Step 5 – Sharding and Reliable Message Delivery for Payment : After a successful purchase, order data must be persisted. The common approach hashes the user ID to distribute orders across multiple databases and tables, dramatically increasing concurrent write capacity. Payment‑related non‑core actions (points, SMS notifications) are decoupled via MQ. To avoid message loss, a local message table records each payment callback; if the system crashes, the table enables asynchronous retries, guaranteeing eventual consistency.

Putting the five steps together yields a complete flash‑sale architecture: Redis distributed lock for qualification → CDN static pages + Nginx rate limiting for read‑traffic → MQ peak shaving + Redis atomic inventory for write‑traffic → Sharded databases + local message table for order persistence and final consistency.

The guiding principle is “layered interception, asynchronous decoupling”: intercept traffic at the earliest possible layer, and make any processing that can be asynchronous truly asynchronous. Mastering this mindset prepares developers not only for interview questions but also for real‑world high‑concurrency scenarios.