Designing a 5‑Layer Flash‑Sale System to Handle Millions of Requests

When a flash‑sale event drives a million simultaneous clicks, the backend must survive the surge without collapsing. The article presents a production‑grade, five‑layer defense architecture that turns the massive burst into a drizzle for the database.

Layer 1 – Overall Architecture Segmentation

Requests travel through six checkpoints: static CDN for images and pages, LVS + Nginx as the first load‑balancing and rate‑limiting barrier, an API gateway for authentication, routing and IP black‑listing, the core flash‑sale service cluster (horizontally scaled), Redis + MQ for hot‑data caching and asynchronous peak‑shaving, and finally MySQL for durable persistence. The guiding principle is to push pressure as close to the user as possible, so each subsequent layer sees less traffic.

Layer 2 – Traffic Funnel

Assuming one million requests for a product that has only one thousand units, 99.9% of the traffic is destined to fail. Early filters therefore matter: the front‑end adds button debounce and captchas, cutting roughly half of blind refreshes; Nginx enforces per‑IP rate limits to stop bots; Redis holds a pre‑stock flag and instantly returns “sold out” when stock reaches zero; finally, a message queue smooths the remaining writes to the database. After these stages, the actual database load may be only single‑digit QPS.

Layer 3 – Redis + Lua Atomic Decrement

Overselling occurs when “check stock” and “decrement stock” are separate, non‑atomic operations. The solution is a Lua script executed inside Redis that performs the check and decrement in a single, uninterruptible step. Benchmarks show a dramatic gap: MySQL pessimistic locking handles only ~120 QPS, while Redis + Lua reaches ~5 600 QPS, a 46× improvement. Adding a segmented‑lock strategy (inspired by ConcurrentHashMap) pushes throughput beyond 8 200 QPS. The industry consensus is therefore to avoid database stock updates and rely on Redis + Lua for atomicity.

Layer 4 – MQ Asynchronous Order Creation

After a successful pre‑stock decrement, the order request is placed onto a message queue instead of writing directly to MySQL. The user receives an immediate “queued, please wait” response. Backend order workers consume messages at their own pace, creating the order, deducting the real stock, and persisting to the database. A delayed message (e.g., 15 minutes later) checks payment status; unpaid orders are closed and stock is returned to Redis. The smoothing effect is intuitive: 1 000 requests × 500 ms processing time, with ten parallel consumers, finish in about 50 seconds, leaving the database idle.

Layer 5 – Order State Machine

Even with all previous safeguards, edge cases such as simultaneous timeout‑close and payment requests can arise. A three‑state machine (Pending, Paid, Closed) combined with optimistic‑lock SQL ensures only the first successful transition wins:

UPDATE orders SET status='Paid' WHERE id=? AND status='Pending'

. Stock updates use UPDATE stock SET stock = stock - 1 WHERE stock > 0 to guarantee no negative inventory. Periodic synchronization copies the true remaining stock from MySQL back to Redis, preventing “under‑selling” caused by cancelled orders.

Core Design Formula

System stability = (Layered Filtering) × (Asynchronous Decoupling) × (Atomic Operations) × (Fallback Mechanisms). Missing any layer can cause a failure during a major promotion, but each layer is relatively simple; the strength lies in their combined depth‑defense approach that filters invalid requests close to the user and lets the database handle only genuine writes.