ACID
Atomicity, Consistency, Isolation, Durability — the classical transaction contract.
Level: intermediate
What is it?
Atomicity: all of a transaction or none. Consistency: integrity constraints hold after commit. Isolation: concurrent transactions do not produce results that no serial order could. Durability: a committed change survives a crash.
Why does it matter?
Ledgers, inventory, and bookings cannot be 'eventually' correct in the small. ACID is the name of that requirement. Distributed systems then explain how expensive it is.
Mental model
A bank transfer is one story: subtract here, add there. Power fails in the middle — atomicity. Two tellers — isolation. The next morning, the story is still there — durability.
How it works
- Atomicity is undo/redo: WAL + rollback.
- Consistency here means constraints (keys, checks), not CAP-consistency.
- Isolation is a spectrum: read committed, repeatable read, snapshot, serializable.
- Durability is fsync (or equivalent) of the log before commit returns.
Real-world usage
- Relational OLTP
- Payment ledgers
- Any 'this row and that row or neither'
Common mistakes
- Using 'consistent' in the CAP sense while talking about ACID.
- Assuming default isolation is serializable (Postgres default is read committed).
Interview questions
Spell ACID with a one-line each.
Atomic: all or nothing. Consistent: constraints hold. Isolated: concurrency does not create non-serial effects. Durable: commit means crash-safe.
How does a WAL give you A and D?
D: the log hits disk before commit returns. A: uncommitted changes are in the log as undo (or not replayed on recovery).