CAP theorem explained: the system design interview concept, done precisely
The CAP theorem is the single most quoted — and most misquoted — idea in a system design interview. State it as "pick two of consistency, availability and partition tolerance" and a good interviewer will immediately push back, because that framing is wrong in a way that decides whether you actually understand distributed systems or just memorised a triangle. CAP is not a menu of three you choose two from; it is a statement about what happens to a replicated datastore at the one moment its network breaks, and the whole value of the idea is the choice it forces on you at that moment.
Here is the version that survives follow-ups. In any system that keeps copies of data on more than one machine, the network will eventually drop or delay messages between those machines — a partition. You do not get to opt out of that; partitions happen whether you planned for them or not. So the real question CAP answers is: when a partition is happening, and a request arrives at a node that cannot reach the others, do you answer it anyway with possibly-stale data, or do you refuse to answer until you can guarantee it is correct? Answer anyway and you chose availability; refuse until correct and you chose consistency. That is the entire theorem, and reaching it in one breath — partitions are not optional, so the choice is consistency versus availability during a partition — is what the round is testing. This guide walks the three properties precisely, the trade-off they really force, how real databases land on each side, and how to use CAP to justify a design decision out loud instead of reciting it.
Why the CAP theorem comes up in system design interviews
CAP surfaces the moment your design has more than one copy of the data — which is almost always. Add a read replica, shard a database, put a cache in front of it, replicate across regions, and you have a distributed datastore whose nodes can lose contact with each other. So any time you say "I'll replicate this for availability" or "I'll use Cassandra here" or "the write goes to the primary and fans out to the followers," you have made a CAP decision, and the interviewer will ask you to defend it.
"Your database cluster is replicated across two data centres, and the link between them goes down for thirty seconds. A write request lands on the side that can't reach the other — do you accept the write and answer, or reject it until the link is back? Pick one, and tell me what the user sees either way."
That question is the whole point. It cannot be answered by naming the theorem; it is answered by knowing that you must choose, picking a side for this specific data, and naming the cost the user pays. The system design rounds here are modelled on how the loop runs, not scraped from any candidate's recall — what matters for prep is the shape: a decision under a partition, and a follow-up that makes you own the consequence.
What the interviewer is really testing
The score is not whether you can recite "consistency, availability, partition tolerance." A good debrief reads on four dimensions, and CAP touches each: problem solving (did you recognise that partition tolerance is forced, so the real axis is C versus A), communication (can you say in one sentence why this data tolerates staleness, or why it cannot), technical execution (can you map the choice onto a real datastore and its replication/quorum behaviour), and time management (did you make the call quickly and move on, instead of drawing the triangle for five minutes). Reading the theorem teaches you the words; it does not teach you to make the call out loud while someone presses on the consequence.
The three properties, precisely
Most wrong answers start with a loose definition, so pin each term down — the precision is where the points are.
| Property | What it actually means | Common misreading |
|---|---|---|
| Consistency (C) | Every read returns the most recent write (or an error). Every node shows the same data at the same logical instant — linearizability, a single up-to-date copy as far as any client can tell. | It is not the "C" in ACID (which is about database invariants and constraints). CAP's C is about reads agreeing across replicas. |
| Availability (A) | Every request to a non-failing node receives a non-error response — the system always answers, though the answer may be stale. | Not "the system is up most of the time." It is a strict guarantee: every request gets an answer, even during a partition. |
| Partition tolerance (P) | The system keeps operating even when the network drops or arbitrarily delays messages between nodes. | Not a feature you can bolt on or leave off — in any multi-node system, partitions are a fact of the physical world. |
The definition that earns the point is consistency: CAP consistency is linearizability, not the ACID "C." Say that out loud and the interviewer knows you have read past the triangle. The other subtlety is availability — it is an absolute: a system is available under CAP only if it answers every request even while partitioned, which is a much stronger claim than "high uptime."
The real trade-off: CP vs AP during a partition
Now the correction that the whole round turns on. The "pick two of three" phrasing implies three symmetric options — CA, CP, AP — as if you freely choose any pair. You do not, because partition tolerance is not negotiable. Networks partition: cables are cut, switches fail, a data-centre link saturates, a GC pause makes a node look dead. If your data lives on more than one machine, partitions will happen, so P is mandatory. That collapses the three choices into one real axis.
So the honest statement of CAP is this: when a partition occurs, you must sacrifice either consistency or availability — you cannot keep both. Consider the request that lands on a node cut off from its peers:
- CP (consistency over availability): the node refuses to answer — it returns an error or blocks — because it cannot guarantee it has the latest write. Data stays correct everywhere; some requests fail during the partition. You chose consistency and gave up availability on the minority side.
- AP (availability over consistency): the node answers anyway from its local copy, which may be stale, and the replicas reconcile later (eventual consistency). Every request gets an answer; some answers are briefly wrong. You chose availability and gave up strong consistency.
"CA" is the one that does not really exist in a distributed system. A CA system is one that assumes partitions never happen — which is only true of a single node (no network between replicas to partition). The moment you have two nodes, the network can split them, and you are forced back onto the CP-versus-AP axis. So in practice CAP is a binary choice made per partition: refuse and stay correct, or answer and risk staleness.
"During the partition, the CP system makes the user see an error on the cut-off side; the AP system makes the user see slightly old data. Which failure is acceptable for this feature? A bank balance transfer wants CP — better to fail the write than double-spend. A social feed's like count wants AP — better to show a stale count than a spinner."
System Design
HLD · Core concept
Defend a CP-vs-AP choice out loud, with follow-ups
CP vs AP in practice, and why PACELC completes the picture
Naming real systems shows you have used this, not just read it — but say the caveat too, because most "AP" and "CP" databases are tunable, so the label is a default, not a law.
| Leaning | Example systems | Default behaviour during a partition |
|---|---|---|
| CP (consistency first) | HBase, MongoDB (default/majority), etcd, ZooKeeper, Spanner | The minority/unreachable side stops serving affected requests; a leader or quorum must be reachable before a write or consistent read succeeds. |
| AP (availability first) | Cassandra, DynamoDB, Riak, Couchbase | Every reachable node keeps answering from its replica; writes are accepted on both sides and reconciled afterwards (eventual consistency, last-write-wins or CRDT-style merges). |
| Tunable (per request) | Cassandra / DynamoDB quorum levels | Consistency is a knob: require more replicas to agree (towards CP) or fewer (towards AP) per read/write. R + W > N buys you read-your-writes. |
The honest add-on that impresses: CAP only describes the partition case, and partitions are rare. What about the 99.9% of the time the network is fine? That is what PACELC captures: if Partition (P), choose Availability or Consistency (A/C); Else (E), choose Latency or Consistency (L/C). In other words, even with a healthy network there is a standing trade-off — synchronous replication for strong consistency costs latency, asynchronous replication for low latency costs consistency. So a full answer sounds like: "This is PC/EL — consistent when partitioned, but tuned for low latency the rest of the time." PACELC is the model that explains why DynamoDB feels fast (EL) and Spanner feels strict (EC) even when nothing is broken.
System Design
HLD · Core concept
Classify a datastore as CP or AP and justify it
How to use the CAP theorem in a system design interview
The mistake is reciting CAP as trivia. The move that scores is wielding it as a decision tool: when you pick a datastore or a replication scheme, say which side of the partition line it sits on and why this data can live with that. Master these five and you are ready for any version of the follow-up.
- "Can't you just have all three?" → No. Partitions are a fact of networks, so P is mandatory in any multi-node system; that forces a choice between C and A during a partition. "CA" only describes a single node that can't be partitioned. (problem solving)
- "CP or AP for this feature — which and why?" → Tie it to the data: strong-consistency-critical state (payments, inventory, unique usernames) is CP — fail rather than serve wrong; staleness-tolerant state (feeds, counts, product catalogues) is AP — answer rather than stall. (communication)
- "What does the user actually see during the partition?" → With CP, errors or timeouts on the cut-off side until it heals; with AP, slightly stale reads and conflicts that reconcile afterwards. Name the concrete symptom, not just the label. (technical execution)
-
"Which real database, and is it really always that?" → Name one (Cassandra = AP, HBase/ZooKeeper = CP) and immediately add that many are tunable per request via quorum (
R + W > N), so the label is a default. (technical execution) - "What about when the network is fine?" → Reach for PACELC: even without a partition there's a latency-versus-consistency choice, so describe the system as PC/EL or PA/EC to show you think beyond the failure case. (problem solving)
Each maps to a debrief dimension. Reading this list teaches you the answers; it does not teach you to deliver them while someone keeps asking "but what does the user see?" — that only comes from saying them out loud.
How to prepare: a short plan
You do not need to memorise a taxonomy. You need the reframe automatic and one or two real systems in each camp so the choice is reflex.
- Day 1: Learn the three definitions precisely — especially that CAP consistency is linearizability, not ACID's C, and that availability is an absolute per-request guarantee. Write each in one sentence.
- Day 2: Internalise the reframe: P is mandatory, so the real choice is C versus A during a partition, and CA is a single-node fantasy. Be able to say the whole theorem in two sentences.
- Day 3: Map real stores — Cassandra/DynamoDB (AP, tunable), HBase/ZooKeeper/etcd (CP) — and learn PACELC so you can describe a system when the network is healthy too.
- Day 4: Drill the application: for ten features (bank transfer, like count, shopping cart, username registration, DNS, chat delivery), say CP or AP and why in one sentence, out loud, then answer "what does the user see during a partition?" each time.
Frequently asked questions
What is the CAP theorem in simple terms?
The CAP theorem says that a system which stores data on more than one machine cannot simultaneously guarantee all three of consistency (every read sees the latest write), availability (every request gets a non-error response) and partition tolerance (the system keeps working when the network between nodes fails). In practice, because networks do fail, partition tolerance is not optional — so when a partition happens you must choose between staying consistent (refuse requests you can't answer correctly) and staying available (answer anyway with possibly-stale data). It is a statement about the trade-off forced on a replicated datastore the moment its nodes can't talk to each other.
Why can't a distributed system have all three of C, A and P?
Because during a network partition, consistency and availability directly conflict. Imagine a node cut off from the rest of the cluster receives a request. To stay consistent it must refuse, since it cannot confirm it has the latest data — but refusing breaks availability. To stay available it must answer from its local copy — but that copy may be stale, which breaks consistency. You cannot do both at once on that node, and since partitions are unavoidable in a multi-machine system (so P is mandatory), you are always forced to sacrifice either C or A when one occurs.
What is the difference between CP and AP systems?
A CP system prioritises consistency: during a partition it stops serving requests it cannot guarantee are correct — the unreachable side returns errors or blocks — so data never diverges, at the cost of some requests failing. HBase, ZooKeeper, etcd and Spanner lean CP. An AP system prioritises availability: during a partition every reachable node keeps answering from its own replica, so no request fails, but different nodes may briefly return different values that reconcile afterwards (eventual consistency). Cassandra, DynamoDB and Riak lean AP. Many of these are tunable per request through quorum settings, so the label is a default rather than a hard rule.
Is a CA system possible?
Not in a genuinely distributed setting. "CA" means a system that is consistent and available but gives up partition tolerance — which only holds if partitions can never happen, and the only way that is true is a single node with no network between replicas to split. A traditional single-server relational database is sometimes called CA, but the instant you replicate it across machines, the network can partition them and you are back to choosing CP or AP. That is why experienced engineers treat CAP as a binary CP-versus-AP choice rather than a menu of three.
What is PACELC and how does it extend CAP?
PACELC fills the gap CAP leaves: CAP only tells you what happens during a partition, which is rare, and says nothing about normal operation. PACELC reads "if Partition, choose Availability or Consistency; Else, choose Latency or Consistency." The "else" branch captures the everyday trade-off — replicating synchronously for strong consistency adds latency, while replicating asynchronously for low latency weakens consistency, even when nothing is broken. So a system is described with both halves: DynamoDB is PA/EL (available when partitioned, low-latency otherwise), while a strict store like Spanner is PC/EC. It is the more complete model to reach for after you've named CAP.
How do I practise using the CAP theorem out loud?
Reading the theorem is not the same as making the call while someone presses on the consequence. On Zynter, the high-level design track runs live voice rounds modelled on how real system design loops run — you talk through a design on the canvas, and a voice interviewer pushes with the follow-ups above one at a time ("the link drops — do you accept the write or reject it? what does the user see?"), then gives you a debrief on problem solving, communication, technical execution and time management. The score is a practice signal, not a hiring decision.
Practise it on Zynter
You can recite CAP. The round is won by making the CP-or-AP call out loud and owning what the user sees.
Pick a high-level design round, reach for the CAP decision when you choose a datastore, and defend it to a voice interviewer that keeps asking "the network splits — do you answer or refuse?" and "what does the user see during the partition?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).
Top comments (0)