What they're testing
Recitation versus use. People who've used transactions know the C is about your constraints, not about data agreeing across nodes.
The short answer~30 seconds
Atomicity: all of it happens or none of it. Consistency: a transaction moves the database from one valid state to another, valid by the CONSTRAINTS you declared. Isolation: how much concurrent transactions can see of each other. Durability: once committed, it survives a power cut. The C is routinely confused with the C in CAP — they are unrelated.
The long answer
Consistency in ACID is close to a passenger letter: it only says that if you declared foreign keys, CHECKs and UNIQUEs, the engine won't let a transaction commit in a state that violates them. Which means most of your "consistency" lives in whether you declared constraints at all. A system that keeps every check in the application layer has almost no C, however capable the engine is.
Consistency in CAP is a different property: every node returns the same answer for the same point in time — close to linearizability. Conflating the two produces meaningless sentences like "Postgres is CP so it's ACID". Being able to state the difference is one of the cheapest ways to score in a senior round.
Durability has more layers than it looks. A Postgres commit writes the WAL and fsyncs it; set synchronous_commit = off and you've traded durability for latency, and a power cut can swallow the last few hundred milliseconds of transactions. That's a reasonable choice for logs and a bad one for payments.
What they'll ask next
?How is atomicity implemented?
Through a write-ahead log: every change is journalled before it touches the data, so on restart the engine can replay what committed and discard what didn't. InnoDB adds undo logs, which serve both rollback and MVCC snapshots.
?Does a transaction roll back automatically if the app dies mid-way?
Yes — when the connection closes, an uncommitted transaction is discarded. But if the process dies without TCP noticing, its rows stay locked until a timeout fires, which is a very common cause of mysterious stalls. Setting idle_in_transaction_session_timeout is the guard.
These lose points
- Explaining the C as "the data is the same on every replica". That's CAP, not ACID.
- Saying NoSQL "doesn't have ACID". Plenty of modern stores offer ACID transactions within a document or a partition; the accurate statement is about scope, not presence.
Sources
- PostgreSQL — Reliability and the Write-Ahead Log
- Martin Kleppmann, Designing Data-Intensive Applications, ch. 7 — "the C in ACID is not a property of the database"