Transactions & Isolation

A transaction groups database operations so they all succeed or all fail together. But grouping alone does not stop two people from buying the last concert seat — for that you need concurrency control: making sure two simultaneous attempts cannot both win.

The animation shows the failure first. Two cursors race toward the same seat; without any lock, both check "is it free?" at the same moment, both see yes, both turn it green — and a red DOUBLE BOOKED alarm fires. The check and the claim were two separate steps, and the second user's check slipped in between the first user's check and claim.

Then the replay with the fix: user A grabs a lock — a padlock appears on the seat, with a 10-second countdown ring. That ring is a TTL (time to live) on the lock, and it matters: if A's app crashes mid-purchase, the lock expires on its own instead of freezing the seat forever. Watch user B's cursor bounce off while the lock holds, then the TTL expire and release the seat.

In interviews, every booking, inventory, or payment question has a "prevent the double-X" deep dive. A status column with an expiry job is an acceptable answer; a Redis lock via SET NX EX (set only if not exists, with expiry) or SELECT ... FOR UPDATE is better.