ACID transactions
Some jobs are made of several steps that must happen together. A bank transfer is the classic one: take $100 from Maya, then add $100 to Ali. If the computer crashes RIGHT in between — after the take, before the add — Maya's $100 has just vanished into nowhere. A transaction is the database's fix: it wraps those steps in one box and promises they ALL happen, or NONE do — never half. ACID is four letters naming the four promises a good transaction keeps.
The story: a transfer that must not lose money
Maya sends Ali $100. The database has to do two separate writes: subtract $100 from Maya's row, and add $100 to Ali's row. Two steps, two different rows. Now imagine the power dies — or the program crashes — exactly between those two steps. Step one ran: Maya now has $100 less. Step two never ran: Ali got nothing. $100 has disappeared. Nobody has it. That's a disaster, and it's not rare — crashes happen all the time on busy servers. The fix is to tell the database: 'these two steps are ONE thing — a transaction. Don't keep one without the other.' Either both are saved (this is called COMMIT) or, if anything goes wrong before the end, both are thrown away as if neither happened (this is called ROLLBACK). The money is never left dangling.
A — Atomicity: all-or-nothing
'Atomic' means 'can't be split' — like an atom (old idea: the smallest piece that can't be cut). Atomicity is the all-or-nothing promise from the story above. A transaction may contain ten steps, but to the rest of the world it counts as a single, unsplittable action. If step seven fails, the database undoes steps one through six too, leaving things exactly as they were before you started. You never end up with 'some of it happened.' Either the whole transaction commits, or the whole thing rolls back. That's why the transfer can't lose money halfway.
C — Consistency: the rules are never broken
A database has rules: 'an account balance can't go negative', 'every order must point at a real user', 'the total money in the bank stays the same after a transfer'. Consistency means a transaction always leaves the database obeying ALL of those rules. If a transaction would break a rule — say, it tries to overdraw Maya's account below zero — the database refuses it and rolls the whole thing back. It will never park the data in a broken, rule-violating state. You hand it a valid database, you get back a valid database, every time. Nothing in between escapes to the outside world.
I — Isolation: don't peek at half-done work
Real databases run many transactions at the same time — thousands of people transferring money at once. Isolation is the promise that each transaction acts as if it's the only one running. While Maya's transfer is half-done (money taken, not yet added), nobody else should be able to SEE that half-finished state. Without isolation you'd get the exact mess from race conditions: two transactions reading the same old number, both writing back, and one update quietly lost. Isolation is the database's answer to that. But 'don't peek' can be enforced strictly (very safe, a bit slow) or loosely (faster, but you might glimpse messy in-between states). That dial has its own whole lesson — isolation levels — coming up next.
D — Durability: once saved, it survives a crash
Durability means: the moment the database tells you 'committed — done!', that change is permanent. Even if the power dies one second later, when the machine boots back up the change is still there. How? Before saying 'done', the database writes the change to a safe place on disk (often a write-ahead log) that survives power loss — not just to fast memory, which forgets everything on a crash. So a committed transaction is carved in stone. This is the difference between 'the computer says it saved' and 'it actually, really saved' — durability is the promise that those two are the same thing.
Questions you might have
▸What's the actual difference between commit and rollback?
Commit means 'I'm done, make all my steps permanent' — the transaction's changes become real and durable. Rollback means 'undo everything I did, pretend I never started' — every change in the transaction is thrown away. A transaction always ends with exactly one of the two: every step kept, or every step erased.
▸Aren't Atomicity and Consistency the same thing?
They're close cousins but different. Atomicity is about the STEPS: all of them happen or none do. Consistency is about the RULES: whatever happens, the database is left obeying its rules (no negative balances, no orphan orders). Atomicity makes the transfer all-or-nothing; Consistency makes sure neither outcome leaves a rule broken.
▸If the power dies mid-transaction, who actually undoes the half-done work?
The database does, automatically, when it restarts. It keeps a log of what each transaction was doing. On reboot it sees 'this transaction never committed' and rolls back its unfinished changes, restoring the before-state. That's atomicity surviving even a crash — you don't have to clean up by hand.
▸Does wrapping things in a transaction make my database slower?
A little — guaranteeing all four promises takes real work (logging to disk for durability, coordinating with other transactions for isolation). But the safety is almost always worth it: a fast database that loses money or corrupts data is useless. You pay a small speed cost to never be 'quietly, silently wrong.'
▸Why is it spelled ACID — is that an accident?
It's a memory trick: the four promises are Atomicity, Consistency, Isolation, Durability, and their first letters happen to spell ACID. That's all — it has nothing to do with chemistry. The letters just make the four guarantees easy to remember.
Best read after: The relational model