ACID

Pradeep P
3 days ago
3 min read

Series: Modern System Design · Layer 4 — Data

Layer 4 · Post 1 of 11

← Previous: Consistency Models → Next: Transactions

Layer 4 — Data · Post 40 of 88

ACID is the contract many databases offer: a transaction either fully happens or it does not, and concurrent work does not tear the data apart.

What you'll learn

What Atomicity, Consistency, Isolation, and Durability each actually promise
Why ACID is a contract with one database, not with your whole architecture
How interviewers use ACID to see if you know when you still have it — and when you have already left it

The idea in one minute

ACID is four guarantees a database can give a transaction — a group of reads and writes you want treated as one unit:

Atomicity: all of it commits, or none of it does. No half-updated rows after a crash.
Consistency: the engine will not commit a state that violates its rules (CHECK, UNIQUE, FOREIGN KEY).
Isolation: concurrent transactions do not see each other's unfinished work. How much they can see is the next two posts.
Durability: once the database says committed, a power cut does not undo it. The write is on stable storage.

BEGIN debit account A credit account B COMMIT --> all four letters apply to this unit

That is the single-database story. Layer 4 exists because a real system is not one database.

Why it matters

Interviewers start here because money, inventory, and bookings are ACID problems until you split them across services.

If you cannot name the four letters and give a counter-example for each, "we will just use microservices" sounds like you have not thought about correctness.

You also need the negative: ACID does not mean your Kafka topic, Redis cache, and Postgres row agree. It means Postgres (or MySQL InnoDB, or SQLite) kept its transaction honest.

How it works

The database wraps your statements in a transaction. If you crash after the debit and before the credit, atomicity rolls the debit back — or never made it visible. Durability is the WAL in Postgres, the redo log in InnoDB: commit means this is on disk (or replicated, depending on fsync and sync-replication settings). Isolation is locks, MVCC snapshots, or both. Consistency is the engine refusing a commit that would break a constraint.

The "C" in ACID is not the "C" in CAP. ACID consistency is invariants inside this database. CAP consistency is every replica showing the same latest write. Mixing those two in an interview is a classic fail.

A simple example

You transfer ₹500 from checking to savings in one Postgres transaction. The CHECK that balances stay non-negative, the foreign keys, and the WAL fsync all fire. Either both rows change or neither does.

A replica may still lag (Layer 1 replication). A Redis cache of "current balance" may still be stale. Those are outside the ACID contract. The contract ends at the commit of this engine.

Common mistakes

Treating ACID as a property of the company. "We are ACID" while dual-writing to Stripe and a local orders table.

Assuming SERIALIZABLE because you said ACID. Default isolation is weaker. Postgres defaults to Read Committed. MySQL InnoDB defaults to Repeatable Read. You can still get surprises. Isolation levels are the next post after transactions.

Skipping durability for speed. UNLOGGED tables, fsync=off, or "an async replica is fine for money" — you traded the D.

How this shows up in real systems

Postgres / MySQL InnoDB / SQL Server: the textbook ACID engines.
SQLite: ACID on one file; great until many machines need to write.
DynamoDB transactions: all-or-nothing across items, with a different isolation story, and not free.
MongoDB: multi-document transactions exist; people still design as if they do not.
Redis MULTI/EXEC: atomic in memory; durability depends on AOF/RDB. Not a ledger.

Recap

ACID is the database's promise for a transaction: all-or-nothing, valid, isolated enough, and on disk.
It does not automatically cover caches, queues, or the next microservice.
Next you need the unit of work itself: transactions — then isolation, locking, and what happens when one database is no longer enough.