You scan a QR code at a chai stall. 20 rupees leaves your account. 20 rupees lands in the stall owner's account. What happens if your phone dies after the debit but before the credit?

The answer is "nothing bad," and the reason is transactions. This is how databases keep banks, UPI, and your Swiggy order from falling apart when things go wrong.

A transaction is a group of statements that succeed or fail together

You wrap a bunch of SQL in BEGIN and COMMIT. Until COMMIT, nothing is permanent. If anything goes wrong, you ROLLBACK and it is as if none of it happened.

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

Either both updates land, or neither does. There is no universe where 20 rupees disappears into the void. That guarantee is the whole point.

ROLLBACK: the undo button

If you spot a mistake mid-transaction, or your code throws an error, you call ROLLBACK instead of COMMIT.

BEGIN;
UPDATE accounts SET balance = balance - 20 WHERE id = 1;
ROLLBACK;

The UPDATE is undone. Nothing was ever saved. This is why every backend framework wraps DB writes in a try/catch with a ROLLBACK in the catch block.

ACID: the four promises

Databases that support transactions promise four things. The acronym is ACID.

• Atomicity. All statements in a transaction succeed, or none do. No half-finished states.
• Consistency. The database moves from one valid state to another valid state. Constraints, foreign keys, and triggers are honoured.
• Isolation. Two transactions running at the same time do not see each other's half-done work. Your UPI debit cannot read someone else's mid-flight credit.
• Durability. Once COMMIT returns, the data survives crashes, power cuts, the works. It is on disk, written down, safe.

ACID is what separates a real database from a glorified spreadsheet. When the RBI mandates "no double debits, ever," ACID is the technical reason it actually holds.

The UPI example, end to end

BEGIN;
 
UPDATE accounts SET balance = balance - 20
WHERE id = 1 AND balance >= 20;
 
UPDATE accounts SET balance = balance + 20
WHERE id = 2;
 
INSERT INTO transactions (from_id, to_id, amount)
VALUES (1, 2, 20);
 
COMMIT;

Three statements. One transaction. The balance >= 20 check inside the UPDATE is your "do you have the money" check, atomically built in. If account 1 has 19 rupees, the UPDATE matches zero rows, your app sees that, and you ROLLBACK instead.

When to use transactions

• Any time you write to more than one row or table and they must agree.
• Money movements, inventory changes, multi-step signups. Always.
• Single-row updates are already atomic at the database level. You do not need an explicit transaction for a one-liner.

Try it on the right

Three transaction assignments. One of them asks you to ROLLBACK on purpose, which is more satisfying than it sounds. Next: window functions, the queries that make senior engineers nod approvingly.