ACID Letter by Letter: Which Failure Each One Actually Prevents

Everyone memorizes ACID. Very few engineers can say, in one sentence per letter, which failure it actually prevents.

Atomicity is all or nothing. A transaction groups several writes. The database guarantees that either every write is visible after commit, or none of them are, even if the process dies mid-flight. The classic example is a money transfer that debits one row and credits another. Atomicity says you never end up with only the debit applied.

Consistency is the slipperiest letter. In ACID, consistency means the database state satisfies whatever invariants you have declared: foreign keys, uniqueness, check constraints, balance non-negative. Most of those invariants are application concerns the database has no opinion about. The DB enforces what you told it to enforce. If you forgot to declare an invariant, ACID will not save you. This is also not CAP consistency, which is a different word reused for a different concept.

Isolation is concurrency safety. Two transactions running at the same time should not see each other's half-written state, and the outcome should be as if they had run one after another. Different isolation levels weaken this guarantee in exchange for throughput. Isolation is where most production money is lost, because it requires you to reason about transactions you did not write running at the same time as the one you did.

Durability is the post-commit promise. Once the database says "committed," that write survives crashes, kernel panics, and power loss. Durability is implemented by writing to the WAL and fsyncing before acknowledging. Without durability, every other guarantee evaporates after a reboot.

The production failure I have watched is a payments team that picked a NoSQL store with "ACID" prominently on the marketing page. They read the docs. The fine print said the ACID guarantees applied within a single document. The application was a ledger. A money transfer touched two documents, one for the source account, one for the destination. The team wrote it as two sequential writes and shipped. For a year it was fine. Then a network blip dropped a connection in between the two writes on roughly two percent of transfers. The result was three hundred thousand dollars of credits with no matching debits, discovered weeks later when the accounting team reconciled.

The fix has two paths. Move the ledger to a real transactional database that supports multi-document atomicity, or implement a journal-and-replay pattern: write the intent to a single durable record, then have a worker idempotently apply both legs and mark the record done. Either way, the lesson is that ACID is a property of a transaction boundary, and the boundary has to match the unit of work that matters to the business.