
Flashsale: Concurrency Control Engine for High-Pressure Checkouts
A System Designed to Handle +100K Active users
⚡ Engineering Challenge: Shared State Under Pressure
Flash sales fail for one reason: shared-state contention. When 100K users hit “Buy” at the same time, a naive “check stock → write order” flow turns the database into a lock. The real challenge wasn’t the endpoint — it was building a control layer that makes the system predictable under chaos.
Backpressure First Stability
Introduced a queue limit at the edge to stop overload early. Instead of letting requests pile up and time out, the system responds fast with a controlled refusal when capacity is reached.
Atomic Stock Reservation No Oversell
Moved stock decisions to Redis atomic counters. The DB remains the source of truth for persistence — but it’s no longer the “gatekeeper” for high-frequency stock checks.
🧠 Approach 1 vs. Approach 2
Under load, a few slow DB operations caused the event loop to backlog. Latency climbed, timeouts started, and the system failed to consume stock reliably during the test window.
The API node performs only three things: (1) capacity check, (2) atomic reservation, and (3) enqueue. Then independent workers handle persistence + payment in parallel. Status updates are streamed via SSE.
🏗️ High-level Architecture
📸 Architecture Evolution (Before → After)
Real diagrams from the project: synchronous request path vs. distributed execution engine.
The pivot was simple: stop doing critical decisions inside the DB request path, and move them into a control layer with measured capacity.
