Imagine transferring ₹1,000 from one bank account to another.
Let's say Jeni has ₹10,000 in his account, and Dravid has ₹5,000.
Jeni wants to transfer ₹1,000 to Dravid.
If everything works correctly, two things happen:
- ₹1,000 is deducted from Jeni's account.
- ₹1,000 is credited to Dravid's account.
Before the transfer:
Jeni → ₹10,000
Dravid → ₹5,000
After the transfer:
Jeni → ₹9,000
Dravid → ₹6,000
Simple, right?
But what happens if something goes wrong halfway through?
Suppose ₹1,000 is successfully deducted from Jeni's account, but before the money is credited to Dravid's account, the application crashes.
Now the database contains:
Jeni → ₹9,000
Dravid → ₹5,000
Jeni has lost ₹1,000, but Dravid never received it.
That's a serious problem.
In real-world applications, failures can happen because of application errors, system crashes, network failures, or other unexpected situations.
So how do databases prevent operations from being left halfway completed?
That's where database transactions and ACID properties come in.
What Is a Database Transaction?
A database transaction is a logical group of one or more database operations treated as a single unit of work.
Note: This is a simplified example created to explain database transactions. Real banking systems involve additional layers of validation, security, and financial processing.
In our bank transfer example, there are two important operations:
UPDATE accounts
SET balance = balance - 1000
WHERE name = 'Jeni';
UPDATE accounts
SET balance = balance + 1000
WHERE name = 'Dravid';
These two operations belong together.
We don't want the first operation to permanently succeed while the second one fails.
Instead, both operations should succeed together.
A simplified transaction might look like this:
BEGIN;
UPDATE accounts
SET balance = balance - 1000
WHERE name = 'Jeni';
UPDATE accounts
SET balance = balance + 1000
WHERE name = 'Dravid';
COMMIT;
Here, BEGIN starts the transaction, COMMIT permanently saves the changes, and ROLLBACK undoes the changes made by the current transaction if something goes wrong before it is committed.
If something goes wrong before the transaction is successfully completed, its changes can be rolled back:
ROLLBACK;
This prevents the database from being left in an unexpected halfway state.
But what makes transactions reliable?
That's where ACID comes in.
What Are ACID Properties?
ACID represents four important properties of database transactions:
- A — Atomicity
- C — Consistency
- I — Isolation
- D — Durability
Instead of memorizing these as definitions, let's understand each one using our bank transfer.
1. Atomicity — All or Nothing
Atomicity means that all operations inside a transaction are treated as one unit.
Either all operations succeed or none of them take effect.
Our bank transfer contains two operations:
- Deduct ₹1,000 from Jeni.
- Add ₹1,000 to Dravid.
If both operations succeed:
Jeni → ₹9,000
Dravid → ₹6,000
The transaction can be committed.
But imagine the system crashes after deducting ₹1,000 from Jeni and before crediting Dravid.
Without proper transaction handling, we could end up with:
Jeni → ₹9,000
Dravid → ₹5,000
Atomicity prevents the transaction from being permanently left in this halfway-completed state.
If the complete transaction cannot succeed, its changes are rolled back.
The accounts return to:
Jeni → ₹10,000
Dravid → ₹5,000
A simple way to remember Atomicity is:
Everything succeeds, or the transaction doesn't happen.
2. Consistency — Keep the Database Valid
Consistency means that a successful transaction should move the database from one valid state to another while respecting the rules and constraints defined for the data.
Let's look at our simplified bank example.
Before the transfer:
Jeni → ₹10,000
Dravid → ₹5,000
Total → ₹15,000
After transferring ₹1,000:
Jeni → ₹9,000
Dravid → ₹6,000
Total → ₹15,000
The money moved from one account to another, but it wasn't magically created or destroyed.
However, consistency is broader than simply keeping the total balance unchanged.
A database may have rules such as:
- A balance cannot violate defined constraints.
- Required values cannot be missing.
- Relationships between records must remain valid.
- Data must satisfy the rules defined by the database and application.
A transaction should not leave the database violating these rules.
A simple way to remember Consistency is:
The database should remain valid before and after a transaction.
3. Isolation — Transactions Shouldn't Interfere Unexpectedly
Real applications don't process only one transaction at a time.
Thousands of users may perform operations simultaneously.
Imagine two transactions happening around the same time:
Transaction A:
Jeni transfers ₹1,000 to Dravid.
Transaction B:
Jeni transfers ₹2,000 to Alex.
Both transactions may try to read or modify Jeni's account balance.
Think of it like two people trying to update the same account at the same time. Isolation helps make sure their transactions don't interfere with each other in unexpected ways.
If concurrency isn't handled correctly, one transaction could read an intermediate value or interfere with another transaction's work.
Isolation controls how concurrent transactions can see and interact with each other's changes.
The goal is to prevent unsafe interference and provide predictable results according to the database's isolation guarantees.
Databases can provide different isolation levels, so this doesn't necessarily mean every transaction literally runs one after another.
A simple way to remember Isolation is:
Concurrent transactions should not expose unsafe intermediate states to each other.
4. Durability — Committed Means Saved
Now imagine our transaction completes successfully.
Jeni → ₹9,000
Dravid → ₹6,000
The database confirms that the transaction has been committed.
Then, one second later, the server crashes.
Should the transfer disappear?
No.
Once a transaction has been successfully committed, Durability means its effects should survive failures such as a system crash.
After the system recovers, the committed information should still be there.
Before the crash:
Jeni → ₹9,000
Dravid → ₹6,000
After recovery:
Jeni → ₹9,000
Dravid → ₹6,000
Database systems use mechanisms such as transaction logs and persistent storage to help provide this guarantee.
A simple way to remember Durability is:
Once committed, the result stays committed.
Putting ACID Together
Let's return to the ₹1,000 bank transfer one final time.
Atomicity
The debit and credit should succeed together or be rolled back.
Consistency
The transaction should preserve the rules that define a valid database state.
Isolation
Other transactions should not interfere with the transfer in unsafe ways.
Durability
Once the transfer is committed, its result should survive failures.
Together, these properties help databases execute transactions reliably.
ACID Is Not Just About Banking
Bank transfers are one of the easiest examples for understanding ACID, but transactional reliability is useful in many other systems.
🛒 E-commerce
Placing an order may involve updating inventory, creating an order record, and recording payment-related information.
These related operations may need to succeed together.
🎟️ Ticket Booking
Multiple users may attempt to reserve the same seat at nearly the same time.
Transaction handling helps prevent conflicting operations from producing incorrect results.
📦 Inventory Systems
A purchase may require stock quantities and related records to be updated together.
The system shouldn't reduce stock while failing to create the corresponding order information.
🌐 Social Platforms
Some actions may require multiple related database changes that need to remain consistent.
The exact transaction design and guarantees depend on the application and database being used.
But the underlying problem remains similar:
Related data changes shouldn't leave the system in an unexpected halfway state.
Final Takeaway
When I first came across ACID properties, the four terms could easily look like definitions that simply needed to be memorized.
But they're much easier to understand when we start with a real-world question:
What happens if a bank transfer fails halfway?
That single scenario explains why reliable database transactions are so important.
Atomicity → All or nothing
Consistency → Keep the database valid
Isolation → Control concurrent transactions
Durability → Committed data survives
The next time you transfer money, book a ticket, or place an online order, remember that behind a simple button click there may be multiple database operations that need to work together safely.
And that's exactly the kind of problem database transactions are designed to solve.
If you're learning SQL or databases too, I hope this bank-transfer example made ACID properties a little easier to understand.
Thanks for reading!
Top comments (0)