ACID and the CAP Theorem
A DabbaGo customer pays ₹180 from her wallet for tomorrow's thali. Two things must happen: her balance drops by ₹180, and an order appears. If the server crashes between the two, she has either paid for nothing or eaten for free. Later, DabbaGo copies its data to a second region for safety, and a new question appears: what should the system do when the two copies cannot talk to each other? ACID and CAP answer these two questions.
The rule
ACID protects one transaction; CAP decides what happens when the network splits.
ACID describes what a database transaction guarantees:
- Atomicity: all of the transaction happens, or none of it. Balance change and order are saved together or not at all.
- Consistency: a transaction moves the data from one valid state to another, respecting rules such as "balance never goes below zero".
- Isolation: transactions running at the same time do not see each other's half-finished work. Two payments from the same wallet at the same moment behave as if they ran one after the other.
- Durability: once the database says "committed", the change survives a crash.
BEGIN;
UPDATE wallets SET balance = balance - 180 WHERE customer_id = 42;
INSERT INTO orders (customer_id, dish, amount) VALUES (42, 'thali', 180);
COMMIT;CAP applies to data copied across machines that talk over a network. It names three properties:
- Consistency: every read sees the latest write, as if there were one copy.
- Availability: every request to a working node gets an answer.
- Partition tolerance: the system keeps running when messages between nodes are lost.
Networks do fail, so a distributed system cannot skip partition tolerance. The real lesson of CAP is: during a partition, you must choose between consistency (refuse some requests until the copies agree) and availability (answer everything, knowing the copies may disagree). When the network is healthy, you can have both.
Note that the C in ACID and the C in CAP mean different things. ACID's C is about valid data by the rules; CAP's C is about all copies agreeing.
The shortcut
For each kind of data, ask: "During a split, is a wrong answer worse than no answer?"
- Wrong is worse → choose consistency.
- No answer is worse → choose availability.
Wallet balances
A wrong answer lets a customer spend the same money in both regions. Wrong is worse: choose consistency and pause wallet payments on the side that cannot confirm.
The trap is reading CAP as "pick any two of three for your whole system". Partitions are not optional, and the choice is made per kind of data, only while the network is split.
Drills
Answer fast — trust the rule.
The server crashes after the wallet is charged but before the order is saved. Which ACID property ensures neither change is kept?
Two payments from the same wallet run at the same moment. Which property stops each from seeing the other's half-finished work?
According to CAP, when must a distributed system choose between consistency and availability?
During a split between regions, which DabbaGo data should favour availability?
What does the C in ACID mean, compared with the C in CAP?
Remember
- ACID: atomicity, consistency, isolation, durability protect one transaction.
- CAP: during a network split, choose consistency or availability; ask "is a wrong answer worse than no answer?"
- Trap: reading CAP as "pick two of three" for the whole system.