Khalil Alyacoubi - Flashsale: Concurrency Control Engine for High-Pressure Checkouts

⚡ 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

Approach 1 (Synchronous): Single API request performs validation, order creation, payment simulation, and DB writes.

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.

Approach 2 (Event-driven): API becomes a fast gate; workers execute the heavy work with explicit concurrency limits.

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

Client │ ▼ NGINX Load Balancer │ ▼ API Nodes (Express) │ ├── Capacity Gate (Queue Limit) │ ├── Atomic Stock Reserve (Redis INCR/DECR) │ └── Enqueue Jobs (Redis Queue) │ ├──► Order Workers (Persist orders → PostgreSQL) └──► Payment Workers (Simulate/Process → Update order) │ ▼ Redis Pub/Sub → SSE Service → Client Updates

📸 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.

Metric

Approach 1

Approach 2

Improvement

Avg API Latency

~1,960ms

~46ms

≈ 42× faster

P95 API Latency

~3,856ms

~195ms

≈ 19× faster

Total Order Time (P95)

~11.7s

~9.5s

≈ 19% faster

Purchase Latency

~1,997ms

~8.7ms

≈ 229× faster

HTTP Throughput

~50 req/s

~258 req/s

≈ 5× increase

Successful Purchases

184

1,275

≈ 593% increase

Order Success Rate

~26%

~78%

+52% absolute gain