What Happens If a Bank Transfer Fails Halfway? Understanding ACID Properties in SQL

Darshan R — Sun, 02 Aug 2026 14:04:26 +0000

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!

DEV Community: Darshan R