Database Transactions and ACID for Financial Data
Why changes to financial data must be grouped into a single transaction, and what the database guarantees when the process fails halfway through.
One business event often requires several data changes at once. Recording a payment means reducing receivables, increasing cash, and marking the invoice as settled. If the process stops after the first step — a dropped connection, a dead server — the data becomes inconsistent: receivables fell with no cash to show for it.
A database transaction solves this by grouping several commands into one indivisible unit. There are only two outcomes: everything succeeds, or everything is undone.
BEGIN;
UPDATE invoice
SET status = 'Paid', amount_remaining = 0
WHERE id = 15821;
INSERT INTO cash_receipt (invoice_id, amount, received_at)
VALUES (15821, 24500000, CURRENT_DATE);
COMMIT; -- anything failing before this line: ROLLBACKThe four ACID guarantees
| Property | What it guarantees |
|---|---|
| Atomicity | Every command in a transaction succeeds together or is undone together |
| Consistency | Data always moves from one valid state to another; rules are never broken |
| Isolation | Concurrent transactions do not see each other's unfinished work |
| Durability | Once committed, data survives even if the power fails a moment later |
Isolation, the one you feel most
When two users process the same data at the same time, the database has to decide what each may see. Loose isolation levels make the system fast but allow reading data that is not final; strict levels protect accuracy but make processes wait for each other. For financial data, accuracy usually wins.