CAP Theorem

CAP is one of the most cited ideas in system design and one of the most commonly misstated — usually as "pick two of three," which makes it sound like a menu. It isn't. Read precisely, it says something narrower and more useful.

The three letters

• Consistency — every read receives the most recent write, or an error. Not "eventually correct" — every read, right now.
• Availability — every request to a non-failing node receives a response. Not necessarily the right response, just a response, and in bounded time.
• Partition tolerance — the system keeps operating even when network messages between nodes are dropped or delayed.

The actual claim

CAP doesn't say "pick two of three" as a permanent design choice — it says that when a network partition happens, you must choose between C and A for the duration of it. Partition tolerance isn't a knob you can decline: in any distributed system, the network between nodes will fail at some point, so a real system doesn't get to be "CA." The honest framing is: every distributed system is a P system, and the only live decision is what it does when a partition occurs — stay consistent by refusing some requests, or stay available by answering with data that might be stale or conflicting.

Concretely: a partition splits your nodes into two groups that can't talk to each other.

A write lands on Side A. Can Side B still serve reads?

• Say no ("I can't guarantee you'd see that write, so I'm refusing") → you've chosen consistency over availability. This is CP.
• Say yes, serving whatever it has, possibly stale → you've chosen availability over consistency. This is AP.

There is no third option that gives you both during the partition — that's the actual theorem (proven by Gilbert and Lynch in 2002, formalising an idea Eric Brewer had stated as a conjecture).

Why this framing matters more than the "pick two" version

"Pick two of three" invites treating C, A and P as three independent features you could all have if the vendor tried hard enough. The precise version makes clear that P isn't optional in a system with more than one node, and turns the real design question into something concrete and answerable: for this specific piece of data, what should happen during a partition? A shopping cart probably favours availability — showing a slightly stale cart beats refusing to load the page. A bank balance probably favours consistency — showing a wrong number is worse than a brief error. Different data in the same system can make different choices, which is why serious answers to "is your system CP or AP" are almost always "it depends which part."

PACELC: the extension worth knowing

CAP only describes behaviour during a partition — which is rare. PACELC (Abadi, 2010) asks the more common question: even with no partition at all, is there an Else trade-off between Latency and Consistency? A system that replicates synchronously to guarantee every read is current pays for it in latency on every write, partition or not. A system that replicates asynchronously answers faster but a read right after a write can see the old value. This is the trade-off that actually governs day-to-day performance for most systems, far more often than the partition case CAP describes — which is why a strong system-design answer mentions both, not just CAP.

Real-world positioning

• A single-primary relational database (Postgres, MySQL in the common configuration) is effectively CP: it favours consistency, and a partition that isolates the primary means writes stop rather than risk two masters diverging.
• Cassandra and DynamoDB are AP by default, with tunable consistency per query — you can request a stronger read (wait for a quorum of replicas to agree) at the cost of latency, which is PACELC's L/C trade-off showing up explicitly as a knob.
• etcd and ZooKeeper, used precisely because distributed systems need one thing everyone agrees on (leader election, configuration), are CP: they'd rather stop answering than let two callers believe different things are true.

This is also exactly the vocabulary the design canvas here expects on a data-platform brief: an architecture edge marked REPLICATION between two data stores is asking, implicitly, which side of this trade-off you made and why — "eventually consistent, chose availability" is a real answer; "consistent" with no acknowledgement of the cost is usually the half that got skipped.

Practice it

The design canvas doesn't grade "CP" or "AP" as a keyword to spot — what matters is the trade-off you actually argue for, on the specific edge you drew it on, in the reasoning notes next to it.

System-design problems