The Cart Locker
The last unit sells exactly once.
The incident
Flash sale, one unit left. Two shoppers hit Buy in the same second. Both saw the stock check pass — because both checks read the database before either write landed. Two confirmations went out. One customer got the product. The other got an apology email, a refund, and a screenshot-worthy reason to never come back.
Why the obvious approach fails
Check-then-act on inventory is the textbook race condition: the check and the decrement are separate operations, and under concurrency, multiple buyers pass the check against the same stock. It's invisible in testing because tests rarely generate true simultaneity — and guaranteed at scale because flash sales generate nothing else. Application-level locks patch one server and break at two. Overselling isn't an edge case to apologize for; it's a structural property of the naive design, and the fix has to be atomic reservation at the data layer, where simultaneity is actually arbitrated.
The standard
- Stock checks and holds are one atomic operation — a reservation with an expiry, taken at add-to-cart or checkout-start per business policy.
- Reservations release automatically on timeout or abandonment; held stock returns to the pool without human cleanup.
- The sellable count is derived: physical stock minus active reservations — never a raw column multiple writers decrement hopefully.
- Oversell is structurally impossible, not monitored-for: a failed reservation means an honest "sold out," never a false confirmation.
- Reservation flow is instrumented — hold rates, conversion, and expiry returns are visible, because they're also merchandising data.
How Cortex validates it
At plan time
Commerce blueprints declare the reservation point, hold duration, and release policy before build.
At validation
assert: concurrent_buys(last_unit) → confirmations == 1assert: expired_reservation → stock_returnedassert: sellable == physical − active_holds (derived, not stored)Assertion syntax is illustrative.
At review
The approver sees the flash-sale simulation: N concurrent buyers, one unit, one confirmation, and the ledger agreeing with the warehouse.