Flash-Sale Inventory Race Condition

Concurrency Mode

Every request reads the stock count, waits out the network round-trip, then blindly writes a decrement. Two requests that read the same value both believe they won — the classic checkout overselling bug.

Flash Sale Parameters

Starting stock 40

Checkout rate 6 req/s

Network + DB latency 220 ms

Live Ledger

Stock remaining

Sold

Rejected

Oversold units

Throughput

0 /s

Queue depth

How it works

Every checkout request runs: read stock → wait L (network+DB round-trip) → write decision. Overselling happens whenever two requests read the same stock value before either one writes — both "see" an available unit and both succeed, driving the real count below zero.

No lock:        write = decrement(stock)                      // unconditional
Optimistic CAS: write = if version==readVersion: decrement, version++
                        else: reject (conflict)
Pessimistic:    resolveTime = max(now, lockFreeUntil) + L        // strict FIFO
                lockFreeUntil = resolveTime

No Lock — models a naive "check quantity, then update quantity" checkout with no atomicity. Whenever the request rate × latency exceeds roughly 1, in-flight reads start colliding and the stock counter can go negative.
Optimistic (CAS) — a compare-and-swap on a version number: the write only commits if nobody else changed the row while this request was in flight. Never oversells, but a losing request must show "sold out" or retry, and conflict (rejection) rate rises with contention.
Pessimistic (Lock) — a single mutex around the whole read-decrement-write, so requests are serialized. Never oversells either, but throughput is capped at 1/latency and a queue builds up under high request rates — visible as a growing "queue depth" readout.

Real-world relevance: this is exactly why mobile e-commerce flash sales (sneaker drops, ticket releases, limited restocks) either oversell without atomic inventory operations, or throttle/queue customers when they use one. Production systems typically use optimistic concurrency at the database row level (a version/ETag column) or a distributed lock / reservation-with-TTL scheme for high-contention SKUs.

In-flight request Sold Rejected / conflict

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.