CAP theorem
Read the transcript
1. The Real Trade-off: CP or AP, Only During a Partition
Host: So everyone throws around ‘CAP theorem’ like it’s a menu — pick any two of consistency, availability, partition tolerance. But that’s not actually what it says, is it?
Guest: No, and that framing has caused a decade of bad architecture debates. Partition tolerance isn’t a choice you get to skip — networks drop packets, that’s just physics and cables. So the real theorem is much narrower: when a partition actually happens, you choose between consistency, meaning linearizability, every read reflects the latest completed write system-wide, or availability, meaning every non-failing node answers every request, even if the answer might be stale. And crucially, that choice only binds during the partition itself.
Host: So the whole ‘three properties, pick two’ thing only matters for a fraction of the system’s actual lifetime. What should people be thinking about the rest of the time, when things are running normally?
Guest: That’s exactly where PACELC comes in, and it’s honestly the more useful everyday frame. It says: if there’s a Partition, choose Availability or Consistency, but Else, during normal operation, you’re really trading off Latency versus Consistency — how long you wait for a strongly consistent answer versus how eventually consistent you’re willing to be. Most real design conversations live in that ‘else’ branch, not in the rare partition branch CAP is actually about.
2. CP in the Wild: Raft and the Numbers Behind the Choice
Host: Okay, let’s make this concrete, because ‘choose availability or consistency’ is still pretty abstract. What does a CP system actually do, mechanically, when a partition hits?
Guest: Take Raft, which underlies etcd, Consul, TiKV, CockroachDB — basically the plumbing under a lot of Kubernetes infrastructure. It keeps one leader per term routing every write through a quorum, floor of N over 2 plus one, so with N=3 that’s 2 nodes. If a partition splits the cluster, the minority side literally cannot reach that quorum, so it stops accepting writes rather than risk diverging from the majority. That’s not a policy choice someone configured, it’s a structural consequence of needing a majority to commit anything.
Host: So the minority side just goes silent on writes until it heals. That maps cleanly onto PACELC too, I’d guess — consensus-backed stores like that are PC/EC, consistent no matter what, and you pay for it in latency even when there’s no partition. Versus a Dynamo-style store that’s PA/EL, available under a partition and latency-preferring the rest of the time?
Guest: Exactly right, and that one-round-trip-to-a-majority write path is why the latency cost is bounded rather than brutal — you’re waiting on the median follower, not the slowest, so R plus W greater than N with W=2, R=2 out of N=3 gives you strong reads without full replication cost. That’s the whole story in numbers: with N=3 you tolerate exactly one node down and stay safe, but lose a second and you’re not, and everything about Raft’s timeouts and elections exists just to make that quorum boundary reliable.
3. Where CAP Gets Misused
Host: So let’s clear the junk drawer of CAP misconceptions, because I think this is where most engineers actually get burned. Starting with the big one — people say ‘pick two of three’ like it’s a menu. What’s wrong with that?
Guest: You never get to drop partition tolerance — a partition happens whether you planned for it or not, so it was only ever CP versus AP. And that’s just the start of the confusion: CAP’s C is linearizability across replicas, not ACID’s C, which is a single node keeping its own invariants — a single-node ACID database has literally nothing to say about CAP. Same with ‘highly available’ — a system can have 99.99% uptime and still be CP, if it refuses writes on the minority side of a partition; the words overlap but the definitions don’t. And ‘eventual consistency’ isn’t one guarantee, it’s a family — read-your-writes, monotonic reads, causal consistency are meaningfully different, and ‘eventual’ alone tells a user nothing about what they’ll actually observe. But the one that matters most for design is that the trade-off is per operation, not per system — the same product can and should make different choices in different places.
Host: Right, we already walked through that example earlier, and nobody’s wrong. And worth saying as we close: partitions are the rare case CAP describes, but the latency cost of consistency is the thing you pay on every single request — that’s the PACELC ‘else’ branch, and it’s honestly the more useful frame to bring into a design review than CAP itself. That’s the whole point of this one — CAP is narrow on purpose, and its value is knowing exactly where it stops applying. That’s a wrap for this episode.
Not covered
The planner wanted these and found nothing in the source to support them:
- A worked, full system-design example applying CAP to a specific AI infrastructure prompt
- Deep dive into vector clocks or logical clocks as an alternative to CAP-style reasoning about ordering
- Discussion of how idempotency and delivery semantics interact with the CP/AP choice
Generated from this page by Claude Sonnet 5 on , spoken by Kokoro-82M running locally. Two synthetic voices, not a recorded conversation. Every claim is drawn from this page — where it differs from the text above, the text is correct.
At a Glance
Section titled “At a Glance”CAP says that when a network partition splits a distributed system, you must choose between consistency (every read sees the latest write) and availability (every request gets a non-error response). It is a statement about behavior during a partition, not a menu of three properties from which you pick two.
The correct reading is narrow: partitions are not optional, so the real choice is CP or AP, and it only binds while the partition lasts. Most of what people want from CAP in a design discussion is actually answered by PACELC.
Key Concepts
Section titled “Key Concepts”| Term | Precise meaning |
|---|---|
| Consistency (the C in CAP) | Linearizability: reads reflect the most recent completed write, system-wide. Not the C in ACID |
| Availability | Every non-failing node answers every request. Not “highly available” in the uptime sense |
| Partition tolerance | The system keeps operating when messages between nodes are dropped or delayed |
| CP | During a partition, refuse or block requests rather than return stale data |
| AP | During a partition, answer from local state and reconcile afterwards |
| PACELC | Partition → A or C; Else (normal operation) → Latency or Consistency |
| Eventual consistency | Replicas converge if writes stop. Says nothing about how long, or what you read meanwhile |
| Quorum | R + W > N gives read-your-writes across replicas; the tunable knob behind most “AP” stores |
| Monotonic reads | You never see time move backwards. A weaker guarantee that is often what users actually need |
Numbers That Matter
Section titled “Numbers That Matter”| Quantity | Value | Why it matters |
|---|---|---|
| Properties you actually choose between | 2, not 3 | Partition tolerance is a fact of networks, not a design option |
| When the CAP trade-off binds | Only during a partition | A CP system is fully available when the network is healthy |
| Quorum condition for strong reads | R + W > N |
N=3, W=2, R=2 is the common default |
Write quorum for N=3 |
2 | Tolerates one node down without losing the guarantee |
| Raft/Paxos partition behavior | Minority side stops serving writes | CP by construction — see the Raft lookup |
| PACELC classification of Dynamo-style stores | PA/EL | Available under partition, latency-preferring otherwise |
| PACELC classification of consensus-backed stores | PC/EC | Consistent in both regimes, paying latency for it |
Common Gotchas
Section titled “Common Gotchas”- “Pick two” is the wrong mental model. You do not get to drop partition tolerance on a system that spans machines; a partition will happen whether or not you planned for it.
- The C in CAP is not the C in ACID. CAP’s C is linearizability across replicas; ACID’s C is a database keeping your declared invariants. A single-node ACID database has nothing to say about CAP.
- “Highly available” is not CAP-available. A system with 99.99% uptime is CP if it refuses writes on the minority side of a partition. The words overlap; the definitions do not.
- Eventual consistency is a family, not a guarantee. Read-your-writes, monotonic reads, and causal consistency are meaningfully different, and “eventual” alone tells a user nothing about what they will observe.
- The trade-off is per operation, not per system. A payment write can be CP while a recommendation read is AP, in the same product. Designs that pick globally are usually picking wrong somewhere.
- The everyday trade-off is latency, not partitions. Partitions are rare; the consistency cost you pay every single request is the PACELC “else” branch, which is why PACELC is the more useful frame in a design round.
Where to Go Deeper
Section titled “Where to Go Deeper”- Module 2: Distributed Systems — consistency models, delivery guarantees, and where each one costs you.
- Raft — the consensus algorithm that makes the CP choice concrete.
- Track: AI Infrastructure System Design — how this trade-off surfaces when the prompt is a real system.
- Daniel Abadi, Consistency Tradeoffs in Modern Distributed Database System Design — the paper that introduced PACELC.