What ACID really promises

Transactions, isolation and locking Junior Python 3.13+ PostgreSQL 17+ Reviewed 31 Oct 2026 By Best Latest Apps

Pick the fix

A transfer debits one account, then the process crashes before the credit. Which property should have prevented the half-done transfer, and how?

OptionsAtomicity: wrap both updates in one transaction so a crash rolls both backIsolation: use SERIALIZABLEDurability: turn on fsyncConsistency: add a CHECK constraint on balance

Hint 1 of 1

The problem is a crash halfway through, not a race.

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Atomicity: wrap both updates in one transaction so a crash rolls both back

Correct. Uncommitted work is discarded on recovery.

Atomicity means a transaction's changes happen together or not at all. If both updates are in one transaction and it never commits, recovery leaves neither visible.

Why not the others?

B Isolation: use SERIALIZABLE. Isolation is about concurrent transactions, not crashes.
C Durability: turn on fsync. Durability protects committed work; this work never committed.
D Consistency: add a CHECK constraint on balance. A CHECK can't see that a matching credit is missing.

30-second answer

Atomicity: a transaction's writes all happen or none do. Consistency: the transaction moves the data from one valid state to another, but 'valid' is defined by your constraints and code, so it is partly the application's job. Isolation: concurrent transactions don't see each other's half-done work, to the degree the isolation level promises. Durability: once COMMIT returns, the change survives a crash, because it is in the write-ahead log on disk.

Practise saying it · 40 s. No recording, just a timer

Explain ACID in under a minute.

Say your answer out loud, then check which of these points you covered:

A: all or nothing
C: valid state, partly the app's job
I: concurrency, set by the level
D: committed survives a crash via WAL

Deep dive

Atomicity is about failure, not concurrency. PostgreSQL gets it from the commit record plus MVCC visibility (rows from an unfinished transaction are never seen); the WAL is what makes commits durable.

The C in ACID is the odd one out: the database enforces only the constraints you declare (NOT NULL, CHECK, UNIQUE, foreign keys).

Isolation is a dial, not a yes or no; most databases default to a weaker level than serializable (PostgreSQL defaults to READ COMMITTED).

Durability depends on settings: synchronous_commit = off trades a small window of lost commits after a crash for speed.

Common mistakes

Saying consistency means 'all replicas agree' (that's the C in CAP, a different idea).
Assuming ACID means serializable by default.
Thinking atomicity protects against concurrent readers.

Senior take & follow-ups

Separate failure (A, D) from concurrency (I), and say plainly that C is shared with the application.

Follow-up questions

Think of your answer first, then open the hint.

Which ACID letter does CAP's C correspond to?
Show hint
None exactly; CAP's consistency is linearizability across replicas.
How does PostgreSQL make commits durable?
Show hint
It flushes the WAL record to disk before COMMIT returns (fsync).

Similar on Android: Relations, transactions and N+1 queries Room wraps SQLite transactions on one device; there is no concurrent writer from another machine.

Suggest a fix if something here is wrong or out of date.