CAP Theorem: Consistency, Availability, and Partition Tolerance Trade-offs
Fast recall
Quick revision
Core answer
Understanding of CAP as it actually applies (only during partition), the CP vs AP trade-off, and real datastore classification.
Treating CAP as 'pick 2 of 3' in normal operation, or claiming a system is 'CA' (impossible if it's distributed across the network).
Discuss PACELC for the no-partition case, explain that consistency itself is a spectrum (linearizability → sequential → causal → eventual), and give concrete examples (DynamoDB tunable consistency, Cassandra QUORUM).
Interview-ready guide
Interview answer
What CAP actually says
During a network partition, a distributed datastore must choose between consistency and availability — you can't have both. Partition tolerance isn't optional in any real distributed system across a network, so the practical choice is CP vs AP.
The most common mistake
People say 'pick 2 of 3 in normal operation.' That's wrong. In normal operation a system can have all three. The trade-off only kicks in during a partition. And 'CA' isn't a real category for distributed systems — that would be a single-machine database with no network.
CP vs AP — the real choice
CP: during partition the minority side refuses writes to keep data consistent. Examples: Zookeeper, etcd, HBase, MongoDB with majority writes, Spanner. Use when correctness matters more than availability — financial ledgers, leader election, distributed locks.
AP: during partition both sides keep accepting writes; conflicts are reconciled when the partition heals. Examples: Cassandra, DynamoDB, Riak. Use when availability matters more than immediate consistency — shopping carts, social posts, view counters.
Mental model: if losing a write or showing stale data is worse than refusing to serve a request, choose CP. If refusing to serve is worse than brief inconsistency, choose AP.
PACELC — the better framework
CAP only describes behavior during partition. PACELC says: if Partition, choose between Availability and Consistency; Else, choose between Latency and Consistency.
Even without partitions, strong consistency requires coordination — quorum reads, Paxos rounds, two-phase commit — which adds latency. Eventual consistency lets writes return immediately and reads hit any replica — lower latency.
Cassandra is AP-EL. DynamoDB default is AP-EL but can be CP-EC with strong reads. Spanner is CP-EC — uses TrueTime for global consistency at the cost of latency.
Consistency is a spectrum
CAP's C is linearizability — strongest. Below that: sequential, causal, read-your-writes, monotonic reads, eventual. Many systems offer tunable consistency per operation.
In Cassandra: R + W > N gives strong consistency. With N=3 replicas, R=W=2 means strong; R=W=1 means eventual but fast.
Implementation
CP via consensus (Paxos/Raft): leader election, quorum writes; minority partition can't form quorum so refuses.
AP via replication + conflict resolution: writes accepted at any node, async replicated. Conflicts resolved by last-write-wins (assumes synced clocks), vector clocks (track causality), or CRDTs (mathematically converge for counters/sets).
Real-world matches
- Financial ledger → Spanner / CockroachDB (CP, EC)
- Shopping cart → DynamoDB / Cassandra (AP, EL)
- Service discovery → etcd / Zookeeper / Consul (CP, EC)
- Social feed → Cassandra (AP, EL)
- Distributed lock → Zookeeper / etcd (CP, EC)
- Analytics counters → Redis or DynamoDB eventual (AP, EL)
If double-spend or split-brain is catastrophic, go CP. If brief inconsistency is recoverable, go AP.
Recommendation
CAP captures the partition trade-off; PACELC extends it to normal-operation latency-vs-consistency. Real systems are CP (Spanner, Zookeeper, HBase) or AP (Cassandra, DynamoDB, Riak); 'CA' isn't a real category for distributed systems. Pick CP when correctness is non-negotiable; pick AP when availability is non-negotiable. Many modern stores let you tune per-operation — so the architectural decision becomes which workloads need which knob.
CAP Theorem: Consistency, Availability, and Partition Tolerance Trade-offs
Direct Answer
CAP says that during a network partition, a distributed system must choose between consistency (C) and availability (A) — it cannot have both. Partition tolerance (P) is non-negotiable in any real distributed system, so the practical choice every datastore makes is CP (refuse writes during partition to keep data consistent — e.g., HBase, Zookeeper, MongoDB with majority writes) or AP (keep accepting writes and reconcile later — e.g., Cassandra, DynamoDB, Riak). PACELC extends this: even without a partition, you trade latency (L) for consistency (C).
Common Mistakes & Pitfalls
Treating CAP as 'pick 2 of 3' in normal operation, or claiming a system is 'CA' (impossible if it's distributed across the network).
Check your understanding
Answer these without looking back at the article.
- Walk through what happens to a Cassandra cluster during a network partition with R=W=QUORUM and N=5.
- When would you choose Spanner over Cassandra for a specific use case?
- Explain how Dynamo-style vector clocks resolve conflicts on concurrent writes.
- Is 'eventual consistency' acceptable for an inventory system at an e-commerce site? Walk through the trade-offs.
Related interview prep categories
2Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.