When Two People Want Seat G7

Friday, 19:58. Two minutes before Night Bus starts on screen 1, and the 8 p.m. show is nearly full. Two customers, Priya and Marco, are looking at the same seat map on their phones, and within the same second both tap the same button: book seat G7.

Isolation, the I from the last page, promised that their transactions won't tangle. This page shows how the promise is kept. The short version: the database briefly makes one of them wait, or fails one of them cleanly, and either outcome beats what the spreadsheet did on that famous Saturday back in Chapter 1. Simultaneity is the everyday miracle databases perform, and it deserves to be seen honestly.

The Race, Replayed Properly

Chapter 1's double-sale is about to be re-staged, this time against the real schema. Both phones send the website's booking code down the same path, and that code runs the same transaction for each customer — only the customer_id differs:

BEGIN;

INSERT INTO bookings (customer_id, screening_id, seat)
VALUES (207, 88, 'G7');

COMMIT;

Two copies of that transaction now race. Here is the whole collision, moment by moment:

Read the last two rows again, because they are the payoff of a promise made back in Chapter 2. The line you were told to remember, UNIQUE (screening_id, seat), is what turns Marco's insert into a clean refusal instead of a second sale. The transaction kept the race orderly; the constraint decided the winner. Neither alone is enough — without the constraint both inserts would land, and without the transaction the refusal could arrive halfway through a multi-step booking. Design and safety, braided together.

Now compare the outcomes. The spreadsheet's Saturday gave two customers the same seat and told no one. The database's Friday gives one customer the seat and the other an honest, immediate no. Marco taps G9, is booked four seconds later, and nobody spends the intermission handing out free popcorn.

Locks, Plainly

The "must wait" row in the timeline is the work of a lock. While a transaction is changing a row, the database holds a lock on it: other transactions that want that same row wait their turn, and everyone else sails past untouched. Marco waited about a twentieth of a second. The dozens of other customers booking other seats that minute never waited at all, because they never wanted the locked row.

A shop's changing room works the same way: one key per room, and the key does the queueing. If the room you want is taken you wait a moment, nobody ever ends up sharing a cubicle, and shoppers heading for other rooms walk straight in. That is the entire mental model — per-row keys, brief waits, and the alternative to waiting is not speed but chaos. Real term from here on: locks.

The Isolation Dial Exists

One honest complication, kept at map altitude. How strictly transactions ignore each other is not a fixed law but a dial. Stricter settings mean more waiting and fewer surprises; looser settings mean less waiting and the occasional strange read. Engines ship with a sensible middle: the common default is called READ COMMITTED, which means your queries only ever see other people's committed work, never their half-done brackets.

That one term is all this book asks you to carry. The full tour of isolation levels, the names of the anomalies, and when to move the dial belong to a deep-dive course. What a beginner needs is to know the dial exists, so that the phrase "isolation level" in a team conversation lands as geography, not magic.

What You Keep

Two working rules fall out of everything above. First: keep transactions short. A bracket holds its locks until COMMIT or ROLLBACK, so a transaction that starts and then waits on a slow web page, or on a person making up their mind, forces everyone who wants those rows to queue behind it. BEGIN, do the work, COMMIT, out. Never BEGIN and go to lunch.

Second: let the database carry simultaneity. The temptation to add your own is_locked column, or to have the app check "is the seat free?" before inserting, is the road back to double-sales — two apps can both pass that check in the same instant and then both write. The constraint plus the transaction close that gap inside the engine, where no timing trick can slip through. You watched it happen at 19:58:01.