CAP theorem is one of the most cited concepts in system design interviews and one of the most consistently misapplied.
The standard failure mode: a candidate mentions CAP theorem as a vocabulary signal (”we need to think about the CAP trade-off here”), states the three letters (Consistency, Availability, Partition tolerance), and moves on without connecting it to a concrete decision.
The interviewer writes “mentioned CAP but couldn’t apply it.” The round continues.
Here’s what applying it actually looks like.
What CAP actually says
CAP theorem says: in the presence of a network partition — when some nodes in your distributed system can’t communicate with others — you must choose between consistency and availability. You cannot have both.
Consistency here means: every read returns the most recent write, or an error. Every node agrees on the current state.
Availability means: every request gets a response. It may not be the most recent data, but the system doesn’t error or time out.
Partition tolerance isn’t a choice — it’s a given. If you’re building a distributed system that runs over a real network, partitions happen. Network cables fail. Datacenters lose connectivity. You cannot opt out of partition tolerance. The real choice is always: when a partition happens, do you stay consistent or available?
Where it actually matters
The question is rarely “should I build a CP or AP system?” That’s too abstract to be useful. The useful version is: for this specific read, how stale can the data be before it causes a real problem?
Some reads tolerate stale data completely. Your Twitter follower count being one minute stale costs nothing. Your Netflix streaming recommendation being 24 hours stale costs nothing. These are candidates for eventual consistency — replicate async, serve locally, accept a brief window of inconsistency.
Some reads cannot tolerate stale data. Your bank account balance must be accurate before a payment is authorized. Your ticket reservation must be current before a seat is sold. These require strong consistency — at the cost of higher latency and potential availability loss during a partition.
The L5 answer isn’t “I’ll use eventual consistency.” It’s: “For the timeline read, I’ll accept eventual consistency — a post appearing 30 seconds late costs nothing. For the payment authorization, I need strong consistency — an incorrect balance check is a real financial loss. These two paths use different consistency models within the same system.”
PACELC: the extension worth knowing
CAP only talks about partition scenarios. PACELC extends the model to the normal case: even without a partition, there’s a trade-off between latency and consistency. If you want every read to reflect the latest write, you need to coordinate across replicas — which adds latency. If you serve from the nearest replica without coordination, you have lower latency but possible stale reads.
Knowing PACELC by name is a mild L6 signal. More importantly, understanding that the consistency/latency trade-off exists even on sunny days is what matters.
The three decisions CAP drives in practice
When you reach the data model step in a design interview, CAP should inform exactly three things:
Replication strategy. Synchronous replication (every write waits for all replicas to confirm) gives strong consistency at the cost of write latency. Asynchronous replication (write confirms when the leader writes, replicas catch up later) gives lower write latency but a brief consistency window.
Read routing. If you route reads to the leader only, you always get the latest data. If you route reads to any replica, you get lower latency but potentially stale data. Pick based on what each read is for.
Conflict resolution. When two nodes accept writes for the same key during a partition, you have a conflict. Last-writer-wins, vector clocks, CRDTs, operational transforms — each is a different answer to the same CAP-induced conflict problem.
The engineers who use CAP well in interviews don’t mention it as a signal. They use it as a decision tool. “For the payment authorization read, I need consistency over availability — I’ll route to the leader and accept higher latency.” That sentence is CAP applied correctly. It doesn’t require saying “CAP” at all.
CTA: The Stripe Payments walkthrough (paid post #2) covers the consistency decisions in a payment system end-to-end — exactly where strong consistency is required, exactly where eventual is acceptable, and why.
Subscription link
https://systemdr.systemdrd.com/subscribe
—Sumedh
The Question Vault has all 52 walkthroughs organized by archetype — so you can see the pattern across questions, not just the surface answer.
Access all 52 Quesstions here