The CAP theorem
Once your data lives on several machines (replication, sharding), they have to talk over a network to stay in sync. Networks break. When the link between your machines snaps, you're forced into a sharp choice: keep answering requests even though your copies might now disagree, or stop answering until you're certain the answer is correct. CAP is the rule that says: during that break, you genuinely cannot have both. You pick one.
The three words: Consistency, Availability, Partition tolerance
CAP is three letters, and the jargon hides simple ideas: Consistency (C): everyone sees the same, latest data. If you change something on one copy, anyone reading any copy sees the new value — never an old one. (Note: this is a different, stricter 'consistency' than the relaxed kind that allows replication lag.) Availability (A): every request gets an answer. The system never replies 'sorry, can't help right now' — it always responds with something. Partition tolerance (P): the system keeps working even when the network between machines splits — when some machines can't talk to the others. A 'partition' is just that: a break in the connection that cuts your machines into groups that can't reach each other.
The real choice: when the network splits, pick C or A
People say 'CAP means pick 2 of 3,' but that's misleading. Here's the honest version. Network breaks are a fact of life — cables fail, machines lose touch — so you don't get to skip Partition tolerance; it's not optional. P is going to happen to you whether you like it or not. So the real decision shows up only DURING a partition, and it's between just two things: C and A. When two copies can't talk and a write arrives on one side, that side faces a fork. Either it accepts the write and answers requests (staying Available) — but now the other side, which never heard about the write, is handing out stale data, so you've given up Consistency. Or it refuses to answer until the link is back and it can be sure everyone agrees (staying Consistent) — but now it's turning people away, so you've given up Availability. There's no third door. That fork is the entire heart of CAP.
The two ticket booths (the analogy that makes it click)
Two ticket booths sell seats for the same concert, and they share a phone line so they never sell the same seat twice. The phone line goes dead — a partition. A customer walks up to each booth at the same time, both wanting seat 14A. Now each booth, alone, must choose. It can SELL the seat to keep the customer happy (stay Available) — but if the other booth does the same, they've sold 14A twice, and two people show up to one chair. That's a consistency failure. Or it can REFUSE to sell until the phone line is back and it can check with the other booth (stay Consistent) — but now it's turning a paying customer away. That's an availability failure. There is no way to both sell every seat AND never double-sell while the phone is dead. Sell-and-risk-conflict, or stop-and-stay-correct: that's C versus A, exactly. That's CAP.
CP or AP — and the choice depends on what the data is for
Because you must pick during a partition, systems are labeled by which they keep: A CP system keeps Consistency and gives up Availability: when in doubt, it refuses to answer rather than risk a wrong one. You'd want this for a bank balance — far better to say 'try again in a moment' than to let someone spend money that isn't there. An AP system keeps Availability and gives up (strict) Consistency: it always answers, even if the answer might be slightly stale. You'd want this for a social media feed — if your like-count is off by one for a few seconds, who cares? Always showing SOMETHING beats showing an error page. Notice the choice isn't about which system is 'better' — it's about what the data is for. The right pick for money is the wrong pick for a feed. CAP doesn't tell you the answer; it tells you the question you must answer.
It's a tradeoff
| Option | 👍 Pro | 👎 Con |
|---|---|---|
| CP — keep Consistency, drop Availability | Answers are always correct and agreed-upon; you'll never act on stale or conflicting data. Right for money, inventory, anything that must be exact. | During a network split it refuses some requests rather than risk a wrong answer — so part of the system goes unavailable until the link heals. |
| AP — keep Availability, drop strict Consistency | Always answers, even during a network split — the system stays up and responsive. Right for feeds, likes, view counts, anything where 'slightly old' is fine. | Different copies can briefly disagree, so a reader may get stale data, and conflicting writes have to be reconciled afterward. |
Questions you might have
▸Why can't I just have all three — Consistency, Availability, AND Partition tolerance?
Because when the network splits, two copies that can't talk are asked the same question. To stay Available, each must answer alone — but without checking the other, they can disagree, breaking Consistency. To stay Consistent, one must refuse to answer until they can check — breaking Availability. During the split, C and A literally pull in opposite directions. You get both only while the network is healthy; the moment it breaks, you choose.
▸What exactly is a 'partition'?
A partition is a break in the network that cuts your machines into groups that can't reach each other — like a phone line going dead between two offices. Both offices still work, they just can't talk. Partitions are unavoidable in any system spread across machines, which is why CAP treats them as a 'when,' not an 'if.'
▸If partitions are rare, why obsess over this?
Because 'rare' isn't 'never,' and when a partition hits, the choice you ALREADY made decides whether your users see wrong data or an error. You can't make the decision in the panic of the moment — it's baked into how you built the system. CAP forces you to choose on purpose, ahead of time, instead of finding out the hard way.
▸Is 'CP' always the safe, better choice? Correct sounds better than available.
No — it depends entirely on the data. For a bank balance, correct beats available: refusing is safer than letting someone overspend. But for a social feed, available beats perfectly-correct: an out-by-one like count is harmless, while an error page is annoying. The same trade that's right for money is wrong for a feed. There's no universally 'safe' pick.
▸How does this connect to replication lag from the replication topic?
They're the same tension in two sizes. Replication lag is a brief, normal delay where a follower is a moment behind — a small dose of giving up strict consistency for speed and availability. CAP is the extreme version: during a full network split, that gap can't close at all, so you must make the C-versus-A choice explicit. Lag is the everyday taste; CAP is the worst-case decision.
Best read after: Replication