Transferring money between two bank accounts requires two separate operations — subtracting the amount from one account, adding it to the other — and if a system crashes or fails partway through, after the subtraction but before the addition, the money simply vanishes from the accounting entirely. Database transactions are built specifically to make that failure mode impossible, by guaranteeing that a group of operations either all complete successfully together, or none of them take effect at all.
Four guarantees, bundled into one word: ACID
Database systems formalise this protection through a set of properties known by the acronym ACID. Atomicity guarantees a transaction is all-or-nothing — if any part of it fails, the entire transaction is rolled back as if it never started, so the money-transfer example can never leave one account debited without the other being credited. Consistency guarantees a transaction can only move the database from one valid state to another, never leaving data in a state that violates the system's own rules. Isolation guarantees that transactions running at the same time don't interfere with each other's intermediate, unfinished results. Durability guarantees that once a transaction is confirmed complete, it survives even a subsequent crash — the change is permanently recorded, not lost if the power fails a moment later.
Why isolation is the hardest one to get right
Atomicity and durability are relatively straightforward to reason about in isolation, but isolation itself gets genuinely difficult once many transactions are running simultaneously against the same data, which is the normal condition for any busy real-world database. Two transactions reading and modifying overlapping data at nearly the same moment can, without careful controls, produce results that depend on the precise, unpredictable timing of which operation happened to execute a fraction of a second before the other — a category of bug notoriously difficult to reproduce and debug, because it may only appear under specific, hard-to-recreate timing conditions.
What we're still unsure about
Achieving full, strict isolation between simultaneous transactions is computationally expensive, so most real-world database systems offer several different isolation levels, deliberately trading off some strictness for better performance, and choosing the right level for a given application is a genuinely difficult, consequential engineering decision rather than a default setting that's always correct. Modern distributed databases, which spread data across many physical machines rather than one, complicate this further — guaranteeing full ACID properties across a distributed system is significantly harder and more costly than on a single machine, and how best to balance strict transactional guarantees against the performance and availability trade-offs of distributed systems remains an active, evolving area of database engineering research.
This sits inside Transactions, ACID & Concurrency Control, one of seven topics in Databases, one of seven domains in Computer Science, one of seventeen subjects the app can quiz you on.