Traced a prod 500 to a race in our deploy from Tuesday and handed me the hotfix

## Root Cause Analysis — `checkout-api` 500 spike **Classification:** race condition (lost update on inventory decrement). **Failure point:** `reserveStock()` reads `stock`, then writes `stock - qty` in two statements. Under concurrent orders for the same SKU, both read the same value and one decrement is lost, driving `stock` negative and tripping the `CHECK (stock >= 0)` constraint — surfacing as the `23514` error in the trace. **Correlation:** lines up exactly with Tuesday's deploy that removed the `SELECT ... FOR UPDATE` row lock during a "performance" refactor. **Blast radius:** only oversold SKUs during traffic spikes — ~0.3% of orders in the last 4h, all recoverable (no charges captured before the constraint fired). **Immediate hotfix** — make the decrement atomic: ```sql UPDATE inventory SET stock = stock - $1 WHERE sku = $2 AND stock >= $1; -- single atomic statement, no read-then-write ``` If `rowCount === 0`, reject with "out of stock." **Long-term:** restore explicit locking or move to the atomic conditional update above as the permanent pattern; add a contract test that fires 50 concurrent reservations for one SKU. **Prevent recurrence:** alert on `rate(pg_errors{code="23514"}[5m]) > 0` and add a dashboard panel for negative-stock attempts.