ACID Without the Acronym Soup
What are the ACID properties in a DBMS, and what guarantee does each one provide?
what they're testing: The interviewer is checking whether you can reason about transaction correctness under partial failure, concurrency, and crashes.
ACID describes four guarantees that make a database transaction reliable when work fails, transactions overlap, or the server crashes. A money transfer is a useful example: put the debit and credit in one transaction so they succeed or fail together.
- Atomicity: All operations in the transaction commit, or none of their effects remain. A failed credit cannot leave the debit behind.
- Consistency: A committed transaction satisfies the database's integrity constraints. The database cannot enforce business rules that were never encoded in constraints or correct transaction logic.
- Isolation: Concurrent transactions are kept from interfering in ways forbidden by the selected isolation level. Only serializable isolation guarantees an outcome equivalent to some one-at-a-time order.
- Durability: After
COMMITsucceeds, the changes survive the crashes or failures covered by the database's configuration and storage guarantees.
These properties solve different problems. Atomicity handles partial work, while isolation handles concurrency. Transaction boundaries still matter: if an order update and its inventory change are committed separately, the database cannot make those two transactions all-or-nothing as a single unit.
Where people slip
the tempting wrong answer, and what's actually true
Atomicity means every statement in a transaction is guaranteed to succeed.
Atomicity does not promise success. It guarantees that all of the transaction's effects commit together or none of them do.
Consistency means every transaction always reads the latest committed value.
Consistency means committed data satisfies the database's integrity constraints. Which committed values a transaction can see is governed by isolation.
Isolation means all transactions always run serially.
Isolation does not require transactions to execute one at a time. Databases run them concurrently, and the selected isolation level determines which anomalies are allowed.
Durability means committed data can never be lost under any circumstance.
Durability protects committed changes against the failures covered by the database's configuration and storage setup, not every disaster or operator mistake. Backups cover risks outside that guarantee.
If they push further
How do transaction isolation levels differ?
Compare the anomalies each level permits, such as dirty reads, nonrepeatable reads, phantom reads, and serialization anomalies. Serializable prevents serialization anomalies, but applications may need to retry aborted transactions.
What is the difference between atomicity and isolation?
Atomicity decides whether one transaction's effects happen as a whole; isolation controls how concurrent transactions can observe and affect one another.
How does a database provide these guarantees?
Common implementations use undo or version data for rollback, write-ahead or redo logs for crash recovery, constraints for consistency, and locking or multiversion concurrency control for isolation. Exact mechanisms vary by database.
Sources
- PostgreSQL 18: Glossary ↗postgresql.org
- PostgreSQL 18: Transaction Isolation ↗postgresql.org
- MySQL: InnoDB and the ACID Model ↗dev.mysql.com
Now answer it yourself.
Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.
beta
The interviewer part is in the works.
The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.