The CAP theorem.
When the network splits, you can keep answering or keep everyone in sync, but not both.
Picture two clerks keeping copies of the same ledger, one in each city, normally syncing every change. One day the phone line between them goes dead. A customer walks up to one clerk and asks to make a change.
The clerk faces a dilemma. Make the change and the two ledgers now disagree. Refuse until the line is back and the customer is turned away. That dilemma is the heart of the CAP theorem.
- 1
Two clerks in two cities keep copies of the same ledger, syncing every change as it lands.
- Hello? …anyone?2
One day the phone line between the cities goes dead. Neither clerk can reach the other.
- Can you update my balance?3
A customer walks up and asks to make a change. Now the clerk is stuck.
- Sorry — come back later.4
Choose consistency: refuse until the line is back, so the two ledgers can never disagree.
- Done — we’ll reconcile later.5
Choose availability: take the change anyway, knowing the two ledgers now tell different stories.
- 6
When the line is healthy you get both. CAP is only the choice you make during the split.
What the three letters are
Consistency: every read sees the most recent write. Availability: every request gets an answer. Partition tolerance: the system keeps working even when the network splits the machines into groups that cannot talk.
In a distributed system, network splits are a fact of life, so partition tolerance is not optional. That leaves the real choice between consistency and availability while a split is happening.
It only bites during a failure
When the network is healthy, you get both consistency and availability — there is no trade to make. CAP is really a guide to how a system should behave in that rare, bad moment when machines lose contact.
Mature systems pick their side on purpose. A bank leans consistent (better to decline than to double-spend); a social feed leans available (better to show a slightly stale like count than an error).