ACID Transactions Explained (Without the Textbook)

I was reviewing a PR last month where a developer had split a payment operation into two separate database calls: one to debit the sender and one to credit the receiver. No transaction wrapping either of them. When I asked why, the answer was, "they're both fast, what's the worst that could happen?" The worst is that the debit runs, your server crashes, and the receiver never gets the money. That's real money gone. ACID exists precisely for moments like that.

ACID is a set of four properties that relational databases guarantee for transactions. A transaction is just a group of operations you want to treat as a single unit. Either all of them happen, or none of them do. The four letters break down what that really means in practice.

Atomicity: all-or-nothing transaction guarantees

Atomicity means a transaction is indivisible. If you bundle five operations into one transaction and the third one fails, the database rolls back the first two as if they never happened.

Think of it like this: you're moving files from one folder to another. Atomicity means the operation either completes fully or leaves everything exactly as it was. No half-moved state, no orphaned data.

In practice, this is what saves you from the "debit ran but credit didn't" problem. If the credit fails, the debit is rolled back automatically.

BEGIN;
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

If anything goes wrong between BEGIN and COMMIT, the database rolls back both updates. Nothing is applied unless everything succeeds.

Consistency: keeping database state valid across transactions

Consistency means the database moves from one valid state to another valid state. Any rules you've set up, like constraints, foreign keys, or check conditions, must hold true before and after the transaction.

If you have a rule that account balances can't go below zero, consistency guarantees no transaction can leave you with a negative balance. The rule is enforced at the database level, not just in your application code.

This is worth paying attention to because application-level validation can be bypassed. Someone queries the database directly, a migration script misses a check, another service hits the same table. Database constraints are the last line of defense.

Isolation: controlling what concurrent transactions can see

Isolation is the property most people get wrong. It controls what one transaction can see from another concurrent transaction.

Imagine two people buying the last item in stock at the same moment. Without isolation, both could read "1 item available," both decide to proceed, and you end up with an oversold inventory. Isolation prevents that kind of interference.

The tricky part is that isolation is a spectrum. Databases give you multiple isolation levels because full isolation is expensive. The four standard levels are:

• Read Uncommitted: you can read data that another transaction hasn't committed yet. Very fast, very dangerous.
• Read Committed: you only see committed data, but if you read the same row twice in one transaction, you might get different results if another transaction committed between your reads.
• Repeatable Read: if you read a row, it stays the same for the duration of your transaction, even if someone else commits a change. MySQL's default.
• Serializable: transactions execute as if they were run one after another, not concurrently. The safest, but the slowest.

Most applications run fine at Read Committed or Repeatable Read. Serializable is there when you genuinely cannot tolerate any anomaly, like in financial ledgers.

Durability: committed data survives crashes

Durability means once a transaction commits, it stays committed. Even if the server crashes immediately after, a power outage hits, or the process is killed, the data survives.

Databases achieve this through write-ahead logging (WAL). Before any change is applied to the data files, it's written to a log. If the system crashes, the database replays the log on startup and recovers to a consistent state.

This is why COMMIT is not just a signal to release locks. It means the database has written enough information to disk that it can reconstruct the committed state no matter what happens next.

Why ACID matters for distributed system design

You stop thinking about ACID as a database detail and start thinking about it as a design constraint when you move toward distributed systems.

The moment you have two services with two databases, you lose ACID across them. A transaction in one database cannot atomically commit with a transaction in another. That's when you start reaching for patterns like the outbox pattern, saga pattern, or two-phase commit, each with its own trade-offs.

Knowing ACID well makes it obvious why those patterns exist. They're all attempts to restore the guarantees you had for free inside a single relational database. None of them are free, and none of them are as clean.

The engineers who understand this distinction design distributed systems with much more realistic expectations. They know when to accept eventual consistency and when to fight hard for stronger guarantees. They don't bolt on a saga pattern because it sounds modern. They reach for it because they genuinely need distributed atomicity and they understand the cost.

If you want to go deeper on related patterns, I covered the outbox pattern and guaranteeing atomicity between a database and a message broker and resilience patterns like retry and circuit breaker. Both topics connect directly to what ACID guarantees inside a single system and what you lose when you step outside it.

Want more system design thinking like this?

Every week in Monday BY Gazar I break down the decisions that separate senior engineers from staff and principal. ACID vs eventual consistency, distributed transaction trade-offs, architecture patterns that actually hold under load. It is a short read, every Monday. Subscribe here.