You can't have all three when the network breaks

There’s a piece of distributed-systems folklore that gets waved around in architecture debates like a trump card: “CAP theorem — pick two of three.” It’s one of the most-cited and most-mangled ideas in backend engineering, and the mangled version leads teams to make a choice they never actually face while ignoring the one they do. Worth getting right, because the moment it describes will happen to any product that outgrows a single database.

Start with the three letters. C — consistency: every reader sees the latest write; ask two servers the same question at the same instant and they agree. A — availability: every request gets a real answer, not an error or a hang. P — partition tolerance: the system keeps working even when the network between your servers drops messages — a switch dies, a data-center link flaps, two halves of your cluster can suddenly no longer talk to each other.

The popular framing — “pick two” — makes it sound like you sit down at the start and choose your favorite pair, as if all three were on the same menu. That’s the part that’s wrong, and it matters. Partitions are not something you choose. They’re something the physical world does to you. Cables get cut, networks glitch; if your system spans more than one machine, a partition will eventually happen whether you planned for it or not. So P isn’t really optional. The real theorem, proved formally by Seth Gilbert and Nancy Lynch in 2002 after Eric Brewer floated it as a conjecture around 2000, says something sharper than “pick two”: while a partition is happening, you must choose between C and A. You cannot have both at that moment.

And you can feel why in about one example, no math required. Two copies of your database, one on each side of a network that has just split. A write lands on side one. Now a read arrives on side two, which hasn’t heard the update and can’t reach the other side to check. You have exactly two options. Answer with the data you have — stay available, but risk handing back a stale value, breaking consistency. Or refuse to answer until you can confirm you’re current — stay consistent, but that request now hangs or errors, breaking availability. There is no third door. The partition forces the pick.

Once you see it as a decision made during the failure rather than a badge you wear, the useful questions change. It stops being “is my database CP or AP?” and becomes “for this operation, which side of stale-vs-unavailable can I live with?” — and the answer differs across your own product. Charging a card, decrementing the last item in stock, moving money between accounts: you want consistency, and you’d rather the operation fail loudly than double-charge or oversell. A like count, a feed, a presence indicator, an avatar: you want availability, and a few seconds of staleness is completely fine — better a slightly-old number than a spinner. Same system, opposite choices, decided feature by feature. That’s the real design work CAP points at, and the “pick two” slogan hides it.

⁂

Two honest footnotes so you don’t over-apply it. First, CAP is about the partition — the rare, dramatic moment the network splits. It says nothing about the vast majority of the time when everything is connected, and it isn’t a general excuse for a system being slow or inconsistent day to day. The more complete framing people reach for now is PACELC, from Daniel Abadi: if partitioned, trade A against C — else, in normal operation, you still trade latency against consistency. That “else” is where you actually live most days. Even with no partition, insisting every read is perfectly fresh costs coordination, and coordination costs milliseconds. Second, C and A aren’t two bins; they’re a dial. Eventually consistent, read-your-own-writes, quorum reads — most real systems sit somewhere on the spectrum, per operation, not at an extreme.

So the takeaway isn’t a two-of-three you memorize. It’s a habit: for each thing your product does, ask what happens to this exact operation the day half your servers can’t reach the other half — and decide, on purpose and in advance, whether it should lie a little or wait a little.