The CAP theorem in depth

The version everyone repeats is wrong, and the wrongness matters

The folklore statement is "consistency, availability, partition tolerance — pick two." That framing fails the moment you take it seriously, because P is not a choice you get to make. A partition is a property of the network: a cut fibre, a failed top-of-rack switch, a bad BGP announcement, an AZ losing connectivity, or — most commonly — a node that is merely slow (a 40-second stop-the-world GC pause, a VM live-migration stall) and is therefore indistinguishable from a dead one. You cannot buy a network that never partitions, so "CA" is not a system design. It is a system with no story for partitions, which under partition quietly gives up both letters.

The precise statement is narrower and far more useful: when a partition occurs, and only then, you must choose between consistency and availability. When there is no partition — which is essentially all of the time — CAP says nothing whatsoever about your system. That last clause is the one that separates candidates: CAP is a theorem about the rare case, and the rare case is not where your latency budget lives.

The three letters, defined precisely (this is where marks are lost)

Two consequences fall straight out of those definitions. First, CAP-A has no latency bound, so a system that answers in 30 seconds is "available" — which is why CAP alone is useless for reasoning about production SLOs. Second, CAP-C is linearizability, the strongest single-object guarantee; weaker useful models (read-your-writes, monotonic reads, causal consistency) sit below it and are perfectly compatible with staying available during a partition. "AP" does not mean "no guarantees."

CAP's own authors and critics say the same. Brewer's 2012 retrospective calls "2 of 3" misleading, because partitions are rare and the choice can differ by operation and data. Kleppmann's critique points out that the formal definitions are ambiguous, that "available" in the proof does not match what operators mean, and proposes reasoning about how operation latency responds to network delay instead. Treat CAP as a vocabulary for partition-time behaviour, not a classification scheme for products.

What CP actually looks like from the client's seat

Take a five-node leader-based cluster — etcd, ZooKeeper, a Spanner Paxos group, a MongoDB replica set with majority write concern. The network splits it 3 | 2.

• Majority side (3 nodes): keeps or elects a leader, keeps committing writes, fully functional. If the old leader was on this side, there is no interruption at all.
• Minority side (2 nodes): cannot reach a quorum, so it cannot commit anything. Writes fail immediately with something like "no leader" or a context deadline. Reads either fail too, or are served locally and are knowingly stale — that is a per-system decision, and a good one to ask about.
• A client pinned to the minority sees hard errors for the entire duration of the partition, plus an election timeout on top (Raft's classic 150–300 ms, etcd's default 1000 ms, ZooKeeper tick-based failover typically a few seconds).

The client-visible contract is: never a wrong answer, sometimes no answer. That is the right trade whenever a wrong answer is more expensive than an error page — a ledger balance, decrementing the last unit of inventory, a cluster-membership record, a lock, a feature-flag kill switch.

Dry run: a 5-node CP cluster split 3 | 2, minute by minute

Nothing in this timeline ever returns a stale or wrong value — that is the entire CP guarantee. The cost is visible in row two: for roughly one election timeout, any client pinned to the minority side gets hard errors and nothing else, which is exactly the "never a wrong answer, sometimes no answer" contract stated above.

What AP actually looks like from the client's seat

Now the same partition in Cassandra at consistency level ONE, or Riak. Both sides accept writes. Every client gets a 200. Nothing appears wrong — and that is precisely the danger, because the damage is deferred to reconciliation time. When the partition heals you have two divergent histories, and something has to merge them:

DynamoDB is a common wrong example here. Inside a Region, each partition has a single Multi-Paxos leader and writes need a majority of its three replicas, so it does not let both sides of a split accept writes; only the eventually consistent reads are served by any replica. Divergent writes appear in global tables in their default multi-Region eventual consistency mode, where last-writer-wins resolves conflicts. Since 30 June 2025 global tables can instead be created with multi-Region strong consistency, which replicates synchronously to at least one other Region and trades write latency for a zero recovery point.

PACELC — the framing that actually predicts database behaviour

Abadi's 2010 extension is the one to bring up unprompted, because it covers the case CAP ignores: if there is a Partition, choose A or C; Else, choose Latency or Consistency. The "else" half applies over 99.9% of your system's life, and it is not a legal technicality — it is forced by physics. Keeping replicas linearizable requires a round trip to a quorum before you can answer, and round trips cost:

Spanner is the clearest illustration of choosing consistency in the "else" branch and simply paying: it is PC/EC, it commits through Paxos across regions, and it adds a deliberate commit wait of roughly twice the TrueTime clock uncertainty (a few milliseconds, per the Spanner paper) so that commit timestamps are globally meaningful. Writes land in the tens of milliseconds. In exchange you get external consistency across a planet, and reads at a past timestamp that a nearby replica can serve without talking to the leader, provided that replica has caught up to the read timestamp (otherwise the read waits for it, so it can still block).

Where real systems sit — the honest, tunable version

The quorum dial: R + W > N

In a Dynamo-style system with N replicas, you require W acknowledgements to accept a write and R responses to serve a read. If R + W > N, the read set and the write set must overlap in at least one replica, so every read touches at least one node that saw the latest write.

The overlap argument assumes the W acks come from the key's real replicas. Riak and the original Dynamo relax that with sloppy quorums and hinted handoff, which keeps writes available during a partition but can leave a read set and a write set disjoint. Cassandra only does so at CL=ANY. And even with strict quorums, R + W > N is not linearizability: concurrent writes need a conflict rule, and a failed write may still surface later.

Using CAP in the room without sounding like a flashcard

The senior move is to refuse the question as posed. Nobody designs "a CP system"; you design a system in which different data has different requirements, and you say so explicitly:

• Payments ledger, account balances, idempotency keys: CP. Refuse the write rather than double-charge.
• Session store, presence, notification counts, feed ranking: AP. A stale unread count costs nothing.
• Inventory: split it. The last 50 units of a SKU are sold through a CP path with a real reservation; the "1,200 in stock" badge on the listing page is AP and can be minutes old. Ticketmaster-style seat selection is the same trick — browse is AP, hold is CP.
• Cluster metadata, leader election, feature-flag kill switches: CP, and delegated to etcd or ZooKeeper rather than built.

Recognizing it in an unseen problem

• The prompt spans more than one datacentre, region, or AZ — the moment replicas can be separated by a network, CAP is live and the interviewer will probe it.
• Words like "globally distributed", "multi-region active-active", "must never lose a write", "must always accept a write" are direct invitations to name your partition-time choice.
• A naive design says "we'll replicate to the other region" and stops. The follow-up that exposes it is always: what does the client see while the link between them is down? Have that answer ready before it's asked.
• Distinguish from the plain replication chapter: replication is about how copies get updated; CAP is about what you do when they can't. Distinguish from PACELC's else-branch: if the network is healthy and you are still arguing about staleness, that is a latency-vs-consistency question, not a CAP question.
• If you choose AP, immediately state the merge function. If you choose CP, immediately state the blast radius: which clients get errors, for how long, and what the retry/queue story is so the user doesn't just see a 500.
• The strongest closing move is to make the choice per-operation and justify each one with the business cost of being wrong versus the business cost of being down.