State the CAP theorem precisely. Why is "pick any two of three" a misleading summary? Give an example of a system where you would choose consistency over availability during a partition, and one where you would choose availability.
Show hints
Partitions are not optional in a distributed system — so what is the real choice?
Show the explanation
Model answer.
The three properties (as used in the theorem)
- Consistency (C): every read returns the most recent completed write — formally, linearizability: the system behaves as if there were a single up-to-date copy. (This is different from the "C" in ACID, which is about integrity constraints.)
- Availability (A): every request to a non-failed node receives a non-error response, without a guarantee that it contains the latest write.
- Partition tolerance (P): the system continues operating even when the network drops or delays messages between nodes.
The theorem: when a network partition occurs, a distributed data store must choose between consistency and availability. A node that cannot reach its peers either refuses or delays the request (preserving C) or answers with possibly stale data (preserving A).
Why "pick two" misleads
- In a real distributed system, partitions will happen (switch failures, cloud zone issues), so P is not optional. The real choice is C or A during a partition.
- It is not binary: many systems offer tunable consistency per operation. The PACELC extension adds: Else (no partition), there is still a trade-off between Latency and Consistency — waiting for replicas to agree costs time.
Choose consistency (CP behaviour)
- Bank balances, seat booking, leader election, configuration — selling the same seat twice is worse than an error. Coordination services such as ZooKeeper and etcd behave this way: a minority side of a partition stops serving writes.
Choose availability (AP behaviour)
- Like counts, shopping carts, view counters — slightly stale data is fine; refusing to work is not. Cassandra and DynamoDB-style systems at low consistency levels accept writes on both sides and reconcile later (e.g. last-write-wins or merging), giving eventual consistency.
Common mistakes: calling a multi-node database "CA" (it must still handle partitions), and confusing CAP consistency with ACID consistency.
Follow-up: "How do quorums relate?" With N replicas, choosing write quorum W and read quorum R such that R + W > N ensures every read overlaps the latest write's replicas (strong reads if implemented carefully); smaller R and W favour availability and latency.
Original UniCircle question. Last reviewed 28 Oct 2026.