CAP Theorem in System Design Interviews: What It Actually Says
Almost every candidate can draw the CAP triangle. Far fewer can answer "so what consistency model are you choosing here, and what breaks because of it?" — which is the question the triangle is standing in for.
What the theorem actually says
CAP says: when a network partition occurs, a distributed system must choose between consistency and availability.
That conditional is the whole theorem, and it is the part that gets dropped. CAP is not a menu where you pick two of three. Partition tolerance is not a property you choose — networks partition whether or not you planned for it. Cables are cut, switches fail, a region goes dark. If your system spans machines, P is a fact of life, not a design option.
Which means the real choice is binary: during a partition, do you return possibly-stale data (AP), or refuse to answer (CP)?
Why "CA systems" do not exist
People describe single-node Postgres as CA. That is not a distributed system, so CAP has nothing to say about it. The moment you add a replica across a network, you are choosing CP or AP whether you name it or not.
If an interviewer asks you to "pick two", the strong move is to gently reframe: "P isn't optional once we're distributed, so what I'm really choosing is what happens during a partition — and for this system I'd choose ___ because ___."
The two choices, concretely
CP — refuse rather than lie. The minority side of a partition stops serving. A quorum system like ZooKeeper, etcd or Consul behaves this way: lose the majority and writes stop. So do leader-elected databases when the leader is unreachable.
Choose CP when a wrong answer is worse than no answer: account balances, inventory counts on the last unit, seat reservations, anything where a double-spend is unrecoverable.
AP — answer, and reconcile later. Every node keeps serving with whatever it has. Dynamo-style stores, Cassandra with low consistency levels, DNS and most caches work this way.
Choose AP when staleness is survivable and downtime is not: a social feed, a product catalogue, view counts, recommendations. Nobody is harmed by a like count that is four seconds behind.
The sentence that does the work
"Eventually consistent" is where candidates get vague. Push yourself to say three things instead:
- How stale can a read be? Milliseconds of replication lag, or minutes?
- What does a client see in the meantime? Their own write (read-your-writes)? Monotonic reads, so values never go backwards? Or genuinely anything?
- How do conflicting writes resolve? Last-write-wins on timestamp, which silently drops data. Vector clocks, which push the merge to the application. Or CRDTs, which merge automatically for the data types that support it.
A counter is the classic trap. Last-write-wins on a counter loses increments — two concurrent +1s become one. That is why real systems use a CRDT counter or a per-replica counter summed on read.
PACELC: the frame that is actually more useful
CAP only tells you about partitions, which are rare. PACELC extends it with the case that applies the rest of the time:
If there is a Partition, choose Availability or Consistency; Else, choose Latency or Consistency.
The "else" branch is where your system lives 99.9% of the time. Synchronous replication to another region buys consistency and costs you a round trip on every write — maybe 80ms across continents. Asynchronous replication is fast and lets a failover lose the last few writes.
Bringing up PACELC unprompted signals that you have thought past the interview-prep version of this topic.
How to use it in an answer
Do not open with the theorem. Open with the requirement, then let the model justify it:
"Balances have to be correct, so for the ledger I'd take a CP path — quorum writes, and during a partition the minority side rejects writes rather than serving a stale balance. The transaction history view can be AP; a few seconds of lag there is fine. So the consistency boundary runs between the ledger and the read models, not across the whole system."
Two things make that answer good. It picks different models for different parts of one system, which is what real architectures do. And it names the cost of each choice rather than asserting a winner.
Reciting "CAP means consistency, availability, partition tolerance, pick two" tells an interviewer you have read about it. Saying which data gets which guarantee, and what a user sees when the network splits, tells them you have thought about it.