1.Two Copies of the Truth

Week thirteen, Friday night. The Friday Stand-Up Night is sold out. At 8:05 PM, Samantha's phone rings: two people are standing at Row C, Seat 14, both holding valid tickets. One bought hers online at 6:02 PM. The other bought his at the venue's box-office kiosk — at 6:02 PM.

On Monday morning, Anna and John dig in. The online checkout keeps bookings in BlueTicket's database. But the old box-office kiosk, written years ago as a quick experiment, still checks and saves its sales in a file on the venue's computer, and only copies them to the database every few minutes.

"So at 6:02, both systems looked, both saw C14 as free, and both sold it," Anna says. John nods. "That's what happens when two things keep their own copy of the truth. Databases exist to stop exactly this."

The shared notebook analogy: imagine a small shop that keeps every sale in one paper notebook on the counter. With one shopkeeper, it works. Now imagine ten shopkeepers, all writing in the same notebook at the same time, some tearing out pages, one spilling coffee on it, and the owner trying to find "all sales to Zoë last March." It falls apart. A plain file on a computer has exactly the same problems.

The bank analogy: now picture a bank. You don't walk into the vault and count the money yourself. You ask a teller, who follows strict rules: checks who you are, makes sure two people can't withdraw the same money at once, records every change, and keeps everything safe even if the lights go out. A database works like the bank's vault and its records together, and the DBMS is the teller.

What a DBMS gives you that a file doesn't: a file is just bytes; you have to write every rule yourself. A DBMS gives you, ready-made:

Many users at once: thousands of programs can read and write at the same time without overwriting each other's work. Rules that are always enforced: "every booking must point to a real seat," "a price can't be negative" — the database refuses data that breaks them. Fast searching: find "every booking for event 42" among millions in milliseconds (chapter 4). Safety: changes are all-or-nothing, and survive crashes and power cuts. Security: who may read or change what. Backups and recovery: a way back if something goes wrong.

The real problem at the venue: it wasn't that the kiosk was slow or badly written. It was that BlueTicket had two sources of truth — the database and the kiosk's file — that only synced every few minutes. For three minutes, each thought C14 was free. The lesson: important data should live in one place that everyone asks, and that place should be a database built for many people at once.

Anna writes the plan for the week on the whiteboard: move the kiosk onto the database, understand how BlueTicket's data is organised, and make sure two sales of the same seat become impossible — not just unlikely. The rest of this Act follows that plan.