Atomicity #
All or nothing; if any step fails, the whole transaction rolls back.
Example
Transferring £100 from A to B requires two steps: debit A, credit B. If the credit fails, the debit is rolled back. Money never vanishes in transit.
Consistency #
Every transaction leaves the database in a valid state; all rules and constraints are enforced.
Example
Account has £50 and a “balance ≥ £0” rule. A withdrawal of £100 is rejected entirely, the database stays valid rather than allowing a negative balance.
Isolation #
Concurrent transactions are isolated from each other and never see each other’s partial state; at its strictest (serializability) each transaction runs as if it were the only one, though most databases use looser isolation levels for performance.
Example
Alice is transferring £100 from Account A to Account B. Halfway through, A is debited but B isn’t credited yet. Without isolation, Bob reading both accounts at that exact moment sees £100 that has simply vanished. With isolation, Bob only ever sees the state before or after Alice’s full transfer, never the in-between.
Isolation Levels
Described here using locks for intuition, though this is an oversimplification. Modern databases use MVCC (Multi-Version Concurrency Control) instead, which keeps multiple versions of rows so readers don’t block writers. The isolation guarantees are the same. MVCC in Databases
- Read uncommitted: no read locks; readers see uncommitted writes from other transactions
- Read committed: read locks released immediately after each SELECT; write locks held until end; rows can change between queries in the same transaction
- Repeatable read: read locks held until end of transaction; write locks held until end; rows can’t change under you but new rows can appear (no range locks)
- Serializable: read, write, and range locks all held until end; nothing can change or appear mid-transaction; prevents all anomalies
Read Anomalies
- Dirty read: a transaction reads data written by a concurrent uncommitted transaction
- Nonrepeatable read: a transaction re-reads data and finds it was modified by another committed transaction since the initial read
- Phantom read: a transaction re-runs a query and finds the result set changed due to another recently committed transaction
- Serialization anomaly: committing a group of transactions produces a result inconsistent with any sequential ordering of those transactions
Isolation Level Dirty Read Nonrepeatable Read Phantom Read Serialization Anomaly Read uncommitted Possible Possible Possible Possible Read committed Not possible Possible Possible Possible Repeatable read Not possible Not possible Possible Possible Serializable Not possible Not possible Not possible Not possible
Durability #
Once committed, data survives crashes and restarts.
Example
The bank shows “Transfer confirmed.” The server crashes one second later. When it restarts, the transfer is still there, it was written to disk before the confirmation was sent.