CAP Theorem definition
The CAP theorem states that a distributed data system can guarantee at most two of three properties at once: consistency (every read sees the latest write), availability (every request gets a response) and partition tolerance (the system keeps working when network links between nodes fail). Because partitions happen, real systems choose between consistency and availability during one.
The three properties
Computer scientist Eric Brewer proposed the idea in 2000, and Seth Gilbert and Nancy Lynch proved a formal version in 2002. The three properties are defined narrowly, which matters, because the everyday meanings of the same words are much looser than the theorem's.
In plain terms, CAP describes what happens when copies of the same data live on different machines that must stay in sync over an unreliable network. It says nothing about single-server databases, and nothing about performance in normal operation, two points that are often misunderstood. The definitions are:
- Consistency: every read receives the most recent write or an error, as if there were a single copy of the data
- Availability: every request to a working node receives a non-error response, though not necessarily the latest data
- Partition tolerance: the system keeps operating even when messages between nodes are lost or delayed
Why the real choice is C or A during a partition
Networks between data centers, and even between racks, do fail. When a partition splits a cluster in two, a node that receives a write cannot confirm it with the other side. It can refuse the request until the partition heals, keeping consistency but sacrificing availability, or accept it and risk the two sides diverging, keeping availability but sacrificing consistency. Dropping partition tolerance is not an option for any system running on more than one machine.
So CAP is less a menu of three and more a statement about failure behavior. Outside a partition, a well-designed system can be both consistent and available; the theorem tells you what it must give up when the network misbehaves.
CP vs AP systems: examples
CP systems choose consistency. Coordination services such as ZooKeeper and etcd, and databases such as HBase or a single-leader relational setup with synchronous replication, reject or delay requests rather than return stale or conflicting data. They suit bank balances, inventory reservations and leader election, where a wrong answer is worse than no answer at all.
AP systems choose availability. Cassandra, DynamoDB with eventually consistent reads and CouchDB keep accepting reads and writes during partitions and reconcile differences afterward, using timestamps, version vectors or application merge logic. They suit shopping carts, social feeds and telemetry. Many databases let you tune this per query, as our SQL vs NoSQL comparison explains.
Beyond CAP: PACELC and practical design
The PACELC extension adds the normal case: if there is a Partition, choose Availability or Consistency; Else, choose Latency or Consistency. Even without failures, keeping replicas strongly consistent across regions costs latency, because writes must wait for distant acknowledgments. That everyday trade-off often matters more to users than rare partitions.
For application teams, the practical lesson is to decide per type of data: money and stock need strong consistency, while counters, recommendations and activity feeds can usually tolerate eventual consistency. Understand what your database actually guarantees, including its replication settings, rather than relying on marketing labels.