CAP theorem
The Question
Explain the CAP theorem and its practical implications.
What a Strong Answer Covers
- All three defined. "Partitions always happen → CP vs AP." CAP vs ACID consistency distinction.
Senior-Level Answer
The CAP theorem, formulated by Eric Brewer, states that a distributed data store can simultaneously provide at most two of three guarantees: Consistency, Availability, and Partition Tolerance.
Consistency means every read receives the most recent write or an error. This is linearizability — not to be confused with ACID consistency.
Availability means every request to a non-failing node receives a response, without guarantee of recency.
Partition Tolerance means the system continues to operate despite network partitions between nodes.
The critical insight: partition tolerance is not optional in distributed systems. Network partitions will happen. So the real choice during a partition is between consistency and availability.
CP systems choose consistency over availability. During a partition, nodes that cannot confirm they have the latest data return errors. Examples: ZooKeeper, etcd, HBase.
AP systems choose availability over consistency. During a partition, all nodes continue serving requests with potentially stale data. Examples: Cassandra, DynamoDB (eventual consistency reads), CouchDB.
A common misconception is that CAP requires you to permanently give up one of the three. The tradeoff only manifests during partitions. When the network is healthy, a well-designed system can provide both. This is why the PACELC extension is more precise: during a Partition, choose A or C; Else, choose between Latency and Consistency.
Another misconception is treating CAP as a system-wide choice. Different subsystems can make different tradeoffs — your auth service might be CP while your product catalog is AP.
Modern databases like CockroachDB and Spanner push boundaries with strong consistency and high availability through consensus protocols, though they still sacrifice availability during severe partitions.
What Separates a 2/3 from a 3/3
2/3 — Passing but Incomplete
Correctly defines all three properties and states the constraint, but lacks concrete system examples or treats CAP as a permanent binary choice.
3/3 — Strong Answer
Defines all three precisely, clarifies that partitions are inevitable, gives concrete CP and AP examples with rationale, and addresses PACELC or per-subsystem tradeoffs.
Common Mistakes
- Treating CAP as a permanent design choice rather than a partition-time tradeoff
- Confusing CAP consistency with ACID consistency
- Claiming you can simply 'choose two' without acknowledging partition tolerance is mandatory
- Not providing real system examples or misclassifying systems
- Ignoring that different subsystems can make different CAP tradeoffs
Follow-Up Questions
- What is the PACELC theorem? — Adds the Else case: when no partition, you still trade off Latency vs Consistency.
- How does Cassandra handle consistency levels? — Quorum reads/writes, ONE, ALL, LOCAL_QUORUM — tunable per-query.
- Can you give an example of a system that appears to violate CAP? — Spanner uses TrueTime for global consistency with high availability, but still sacrifices availability under severe partitions.
- How would you decide whether a microservice should be CP or AP? — Assess the cost of stale data vs. unavailability for that specific domain.
- What is eventual consistency and what guarantees does it actually provide? — All replicas converge given no new writes; no bound on convergence time.
Related Questions
Can You Explain This Cold?
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment