Transactions and ACID

Why a bank transfer never loses money halfway

A transaction is a group of database changes that succeeds or fails as one unit: either every change happens or none does. Moving £30 from Alice to Bob is two writes, take 30 from Alice and add 30 to Bob, wrapped between BEGIN and COMMIT.

ACID names four promises. Atomicity: all or nothing. Consistency: rules like "balance ≥ 0" always hold. Isolation: simultaneous transactions don't see each other's half-done work. Durability: once committed, it survives a crash.

If the server dies after debiting Alice but before crediting Bob, atomicity means that half-done debit is undone on restart. The £30 never vanishes into the gap.

Transactions and ACID

Your phone's apps use SQLite, which survives a dead battery mid-save

Android and iOS ship SQLite, a small database that many apps use to store messages, contacts and settings. Its transactions are atomic even if power is cut in the middle of a write, a guarantee the SQLite developers document and test.

If your battery dies while an app saves a batch of messages, you'll find the whole batch saved or none of it, never a broken database. PostgreSQL and MySQL's InnoDB give banks and shops the same promise.

Transactions and ACID

The database keeps a way back until one final "commit" mark is written

Inside a transaction, the database records enough information to undo each change, and nothing counts as final yet. The moment that decides everything is the commit: a single small record written to disk saying "this transaction is done".

One record is either written or not, so there's no in-between. On restart the database checks for it: committed transactions are kept, others are rolled back (undone). How that log works efficiently comes in a later lesson.

If a rule fails partway, say Alice's balance would go below zero, the database aborts and rolls back the whole transaction, so Bob is never credited money that wasn't taken.