ACID transactions.
A bank transfer that cannot half-happen: either the whole thing lands, or none of it does.
Moving £100 between accounts is really two steps: subtract from one, add to the other. If the power cuts out between them, the money must not vanish into thin air.
A transaction groups those steps so they behave as one indivisible action. ACID is the set of four promises a database makes about transactions like this.
- 1
Moving £100 is really two steps: take it from one account, add it to the other.
- Where did my £100 go?!2
If the power cuts between the two steps, the money must not vanish into thin air.
- 3
A transaction fences both steps so they behave as one indivisible action — atomicity.
- Both landed. Sealed.4
If every step succeeds, commit: lock it all in at once and it survives a crash a second later.
- Never mind — put it back.5
If anything fails, roll back: undo everything, as if it never happened.
- 6
The four promises: atomic, consistent, isolated, durable — why a database feels trustworthy.
What the four letters promise
Atomicity is the all-or-nothing rule above. Consistency means the database never ends up in an invalid state — rules and constraints always hold. Isolation means concurrent transactions do not see each other’s half-finished work. Durability means once it says "committed", a crash a second later will not lose it.
Together they are why a traditional database feels trustworthy: you can reason about it as if one thing happens at a time and nothing is ever left half-done.
Why it is not free
Keeping these promises takes coordination — locks, logs, and careful ordering — which costs some speed and gets harder when data is spread across many machines.
That is exactly why some large, distributed systems deliberately relax the strict rules in exchange for scale and availability, accepting weaker guarantees where the business can tolerate them.