CAP theorem shows up in almost every system design interview, and most explanations of it are bad. People recite "consistency, availability, partition tolerance, pick two" and move on. That phrasing is wrong, and if you repeat it in an interview, a good interviewer will press you and watch you fold.
Here's the version that actually holds up.
What the three words mean
First, get the definitions right, because the interview-flashcard versions are sloppy.
Consistency here is not the C in ACID. It means linearizability: every read sees the most recent write. If I write x = 5 and then you read x, you get 5, not some older value. All clients see one agreed-upon version of the data.
Availability means every request to a non-failing node gets a non-error response. Not fast. Not correct. Just an answer instead of a timeout or a 503.
Partition tolerance means the system keeps working when the network drops or delays messages between nodes. A partition is when node A can't talk to node B, even though both are alive.
You don't actually pick two
This is the part the flashcard version gets wrong. You do not freely choose two of the three.
In any real distributed system, network partitions happen. Cables get cut, switches reboot, a deploy misconfigures a security group. You cannot opt out of partitions. So P is not optional. It's a fact about the world.
That means the real choice is only what you do during a partition. When A and B can't talk to each other, and a write comes in:
- You can refuse the write (or refuse reads) to avoid serving stale data. That keeps consistency and gives up availability. This is CP.
- You can accept the write on whichever node you can reach, knowing the two sides now disagree. That keeps availability and gives up consistency. This is AP.
So CAP is really a choice between C and A, but only while a partition is happening. When the network is healthy, you can have both. CAP says nothing about the normal case.
That's the whole insight. "Pick two" should be "when the network breaks, do you sacrifice correctness or do you sacrifice answering."
What this looks like in real systems
A bank ledger leans CP. If two data centers can't sync, you'd rather an ATM say "try again later" than let someone withdraw the same balance twice. Refusing service is annoying. Double-spending is a lawsuit.
A shopping cart or a social feed leans AP. If a partition means you show a slightly stale like count or accept a cart update that reconciles later, nobody gets hurt. Staying up matters more than being perfectly current. Dynamo-style stores were built around exactly this tradeoff.
Notice these are per-feature, not per-company. The same product can run a CP path for payments and an AP path for the activity feed. In an interview, saying "this part of the system is AP and this part is CP, for these reasons" is a much stronger answer than labeling the whole design with one letter.
The thing CAP leaves out: latency
CAP is a model about failures, and it's binary - partition or no partition. Real systems live in the messy middle, where the network is technically up but slow.
That's where PACELC comes in, and it's worth one sentence in an interview. PACELC extends CAP: if there's a Partition, choose A or C (the CAP part); Else, in normal operation, choose between Latency and Consistency.
Even with no partition, keeping nodes perfectly consistent costs round trips. You can wait for every replica to acknowledge a write (more consistent, slower) or reply early and replicate in the background (faster, possibly stale). Most of your day-to-day system behavior is this latency-vs-consistency knob, not the dramatic partition case. Mentioning PACELC signals you understand the part CAP doesn't cover.
How to use this in an interview
If CAP comes up, don't lead with "pick two." Say something like:
"Partitions are going to happen, so the real question is what we do during one. For payments I'll stay consistent and reject writes if replicas can't agree. For the feed I'll stay available and reconcile afterward. And outside of partitions, the live tradeoff is latency versus consistency, which I'll tune per endpoint."
That's three sentences and it tells the interviewer you actually understand the thing instead of having memorized it.
A couple of follow-ups they'll often ask, so have an answer ready:
- "How do you reconcile after an AP partition heals?" Last-write-wins with timestamps, version vectors, or app-level merge logic. Know that last-write-wins can silently drop data.
- "What does the user see during a CP partition?" Errors or timeouts on the affected path, which means you need retries and a clear failure mode in the client.
CAP is small. It's one forced choice during one specific failure. Once you stop treating it as a trivia question and start treating it as a per-feature design decision, it gets a lot easier to talk about, and a lot more useful when you're actually building something. If you want it to stick, try drawing the partition out on a whiteboard and walking through both branches out loud, the same way you'd have to in a mock interview.