1. Transactions and isolation

Two guests on a hotel booking platform tap "Book" for the last free room on the same nights, a few milliseconds apart. Each request checks that the room is free, saves a booking row, and takes the price out of the guest's wallet.

• A transaction is how the database keeps a group of reads and writes like that together: it either commits all of them or none of them.
• Isolation is the rule for how much two transactions running at the same time can see of each other.

Without the right transaction and isolation rules, the hotel can sell one room twice or charge a guest for a booking that never saved.

This topic rarely gets its own interview segment. It shows up as a follow-up once your data model is on the board, usually for three to eight minutes: "What stops a double booking?" or "Can the booking and the debit still commit together after you shard?" Saying "use a transaction" is where mid-level answers stop. Interviewers for backend and infrastructure roles, and for senior levels, want the specific anomaly and the specific fix.

This tutorial stays inside one database's commit scope and then shows where that scope ends. You'll learn what ACID (atomicity, consistency, isolation, durability) actually promises, which concurrency anomalies each isolation level allows, how write skew double-books a room and how to stop it, and why a write that crosses shards stops being one cheap transaction.