Backend & Data
The CAP theorem, in plain English
The CAP theorem gets stated as "pick two of three: Consistency, Availability, Partition tolerance" — which is technically true and completely misleading. The real story is sharper and more useful: networks will break, and when they do, a distributed database has to choose between giving you an answer that might be stale, or giving you no answer at all. There's no third option, and that's the whole point.
The three letters
- Consistency — every reader sees the latest write. Ask any node and you get the same, current answer.
- Availability — every request gets a (non-error) response. The system always answers.
- Partition tolerance — the system keeps working even when the network between nodes drops messages or splits them into isolated groups.
Why it's really a two-way choice
Here's the part the "pick two" framing hides: if your data lives on more than one machine, partitions are a fact of life — cables cut, routers hiccup, data centres lose their link. You don't get to opt out of P. So the genuine decision only appears during a partition, when two nodes can't talk: do you
- keep answering with whatever data you have, risking that it's stale (choose Availability), or
- refuse to answer until you're sure it's correct (choose Consistency)?
When the network splits, a distributed database must pick: give a possibly-wrong answer (stay available), or give no answer (stay consistent). You can't have both at that moment. That's CAP.
What it means in practice
CP systems (many SQL setups, etcd, ZooKeeper) favour correctness — during a partition they'd rather return errors than serve stale data. Use them where being wrong is worse than being down: money, inventory, locks. AP systems (Cassandra, DynamoDB, DNS) favour staying up — they answer even if the data might be slightly behind, and reconcile later ("eventual consistency"). Use them where being down is worse than being briefly stale: feeds, carts, caches, analytics.
Notice the last examples: a CDN and a cache are deliberately AP — they serve you a possibly-old copy rather than make you wait. CAP isn't an abstract puzzle; it's the reason your system behaves the way it does the day the network misbehaves. Decide which failure you can live with before that day arrives.