CAP Theorem: Consistency, Availability, Partition Tolerance
The CAP theorem states that during a network partition, a distributed system must choose between Consistency (every read sees the latest write) and Availability (every request gets a response). Partition tolerance isn't optional in real networks, so systems are effectively CP (consistent, may reject requests) or AP (available, may serve stale data).
What CAP Actually Says
Formulated by Eric Brewer in 2000 and proved by Gilbert and Lynch in 2002, the CAP theorem covers three properties: Consistency (all nodes see the same data at the same time, specifically linearizability), Availability (every non-failing node returns a response), and Partition tolerance (the system keeps working despite dropped/delayed messages between nodes).
The common phrasing 'pick two of three' is misleading. Network partitions are a fact of life in distributed systems, so you can't sacrifice P. The real choice is: when a partition happens, do you stay Consistent (refuse requests that can't be made consistent) or Available (answer with possibly stale data)?
CP vs AP Systems
A CP system (e.g., HBase, MongoDB with majority writes, etcd, ZooKeeper, Google Spanner) prioritizes consistency: during a partition, the minority side rejects requests rather than risk stale data. Good for systems where correctness matters more than uptime, like financial ledgers, leader election, and configuration stores.
An AP system (e.g., Cassandra, DynamoDB, Riak, CouchDB) prioritizes availability: every node keeps answering, accepting that replicas may temporarily diverge and reconcile later (eventual consistency, read repair). Good for shopping carts, social feeds, and metrics where stale-but-available beats unavailable.
| System | CAP class | Behavior on partition |
|---|---|---|
| Cassandra, DynamoDB, Riak | AP | Stays available, may serve stale data |
| Spanner, etcd, ZooKeeper, HBase | CP | Rejects requests to preserve consistency |
| MongoDB | CP (tunable) | Reads from majority; minority unavailable |
PACELC: The Fuller Picture
CAP only describes behavior during partitions. PACELC (Abadi, 2012) extends it: if there's a Partition, trade between Availability and Consistency; Else (normal operation), trade between Latency and Consistency. This captures the everyday cost of strong consistency, synchronous coordination across nodes adds latency even with no partition.
Example: DynamoDB and Cassandra are PA/EL (favor availability under partition, low latency otherwise). Google Spanner is PC/EC (always consistent, paying latency for synchronized clocks via TrueTime). This framing is more useful in interviews because most systems run partition-free 99.9% of the time, where the latency/consistency tradeoff dominates.
ResuMax tailors your resume to each role, scores it like a recruiter, and preps you for interviews.
Practice with the interview coachFrequently asked questions
Can a system be CA (consistent and available)?
Only in a system with no network partitions, which doesn't exist across a real network. A single-node database is effectively CA, but any distributed system must tolerate partitions, so the meaningful choice is CP vs AP.
Is the CAP theorem about giving up partition tolerance?
No. Partitions happen in real networks whether you plan for them or not, so P is non-negotiable. CAP forces a choice between consistency and availability only during a partition, not a free choice among all three.
What is PACELC and why is it better than CAP?
PACELC adds the normal-operation tradeoff CAP ignores: during a Partition choose Availability or Consistency; Else choose Latency or Consistency. Since systems run partition-free most of the time, the latency-vs-consistency tradeoff is often the more practically important one.
Is MongoDB CP or AP?
MongoDB is primarily CP: with majority write concern and primary reads, the minority side of a partition can't serve writes or consistent reads. It's tunable, looser read/write concerns trade consistency for availability and latency.