Imagine you’re building a banking application.
A customer wants to transfer money, and your system needs to:
Deduct the money from their account
Credit the recipient’s account
Record the transaction in the ledger
But what happens if the system crashes after deducting the sender’s balance but before crediting the recipient? Or if the database errors halfway through the process?
This is exactly the kind of problem ACID transactions are designed to solve. They ensure that all the steps in critical operations happen reliably and consistently.
In this article, we’ll break down what ACID means, why it’s important, and how databases implement these properties.
What is a Database Transaction?
A transaction is a sequence of one or more operations (like insert, update, or delete) that the database treats as a single action.
It either:
fully succeeds, or
fully fails (with no partial changes).
Example: Money Transfer
When you transfer money to a friend, two things must happen:
Money is deducted from your account.
Money is added to their account.
These steps form a transaction. If either one fails, the whole thing is rolled back.
Without transactions, we risk:
Partial updates (money deducted from your account but never credited to your friend).
Conflicts (two people withdrawing the last funds at the same time).
That’s why databases enforce ACID properties: Atomicity, Consistency, Isolation, Durability.
- Atomicity
Atomicity means a transaction executes as a single, indivisible unit of work.
It either:
commits fully, or
rolls back completely.
Example: In a money transfer, if the credit to the recipient fails, the debit from the sender must also be undone. This prevents money from “disappearing.”
How Databases Implement Atomicity
Transaction Logs (Write-Ahead Logs)
Every operation is written to a log before touching the actual tables.
If a crash happens, the database replays or undoes operations based on the log.
Commit / Rollback Protocols
Commands like BEGIN TRANSACTION, COMMIT, and ROLLBACK define the boundaries.
If any operation fails, the database restores the original state.
- Consistency
Consistency ensures that a transaction moves the database from one valid state to another.
If rules are broken, the transaction fails.
Example:
In a banking system, an account balance cannot go below zero (unless overdraft is allowed).
If a withdrawal transaction tries to set the balance to -200, the database rejects it, keeping the system in a valid state.
How Databases Enforce Consistency
Schema constraints (NOT NULL, UNIQUE, PRIMARY KEY, CHECK).
Triggers & stored procedures to validate account balances.
Application-level checks before sending data to the DB.
- Isolation
Isolation ensures that concurrent transactions don’t interfere with each other’s intermediate states.
Without isolation:
A customer might see a balance that reflects a half-completed transfer.
Two withdrawals could both think enough funds exist, overdrawing the account.
Isolation Levels
Databases let you choose between performance and correctness:
Read Uncommitted → allows dirty reads (rarely used).
Read Committed → prevents dirty reads (most common default).
Repeatable Read → prevents dirty & non-repeatable reads.
Serializable → the strictest, as if transactions run one by one (but slowest).
How Isolation is Implemented
Locking (pessimistic control) → rows/tables are locked until a transaction finishes.
MVCC (optimistic control) → multiple row versions exist, so readers see a snapshot while writers update in parallel.
Snapshot isolation → each transaction works with a consistent snapshot until it commits.
- Durability
Durability guarantees that once a transaction is committed, it stays committed — even if the system crashes.
Example: Once your bank confirms a transfer, that record is safe. Even if the system goes down, the debit and credit remain.
How Databases Guarantee Durability
Write-Ahead Logs (WALs)
Changes are recorded to durable storage before being applied.
On restart, committed operations are replayed; uncommitted ones are rolled back.
Replication
Synchronous replication → data is written to multiple nodes before commit.
Asynchronous replication → data is written to replicas later (small risk of loss).
Backups
Full, incremental, and off-site backups provide extra resilience beyond WAL and replication.
Wrapping Up
ACID properties ensure that:
Atomicity: All-or-nothing execution.
Consistency: Valid states before and after transactions.
Isolation: Transactions don’t interfere with each other.
Durability: Committed changes survive crashes.
Without ACID, modern banking systems would be unreliable — balances could vanish, transfers might only complete halfway, and customers would lose trust.
Top comments (0)