A network switch fails and splits your database cluster in two. A write lands on one side. A read hits the other. Do you answer with data you know might be stale, or do you refuse the read until the network heals? That single decision is the CAP theorem in one sentence.
This note covers what the CAP theorem actually claims, why "pick two of three" is the wrong way to remember it, and how real databases like Cassandra and etcd land on opposite sides of the choice.
What does the CAP theorem state?
The CAP theorem states that when a network partition splits a distributed data store, the system can preserve either consistency or availability, but not both at once. The three letters are consistency, availability, and partition tolerance, and no system can hold all three during a partition.
Eric Brewer presented this as a conjecture in his keynote at the PODC symposium in 2000. Seth Gilbert and Nancy Lynch proved it formally in 2002, for the asynchronous network model where messages can be lost. So this is a proven impossibility result, not a rule of thumb.
The three guarantees, in the precise sense Gilbert and Lynch used:
- Consistency means every read returns the most recent write or an error. They call this atomic, and it matches what most people now call linearizable. There is one logical copy of the data.
- Availability means every request that reaches a working node gets a response. The response is never an error, though it might be stale.
- Partition tolerance means the system keeps running even when the network drops arbitrarily many messages between nodes.
How does the trade-off actually work?
The trade-off appears only during a partition, when two groups of nodes can no longer talk to each other.
Walk through it. Two replicas both hold X = 1. The network between them breaks. A client writes X = 2 to the left replica. Now a second client reads from the right replica, which never saw the write. The system has exactly two honest options:
- Stay consistent (CP). The right replica refuses to answer, because it cannot prove its copy is current. The read fails. Data stays correct, and availability is lost for that request.
- Stay available (AP). The right replica answers with
X = 1, the value it has. The request succeeds, but the answer is stale. Availability is kept, and consistency is lost.
There is no third door. As long as the partition lasts, returning a fast and correct answer from both sides is impossible, because the two sides disagree and cannot reconcile until they can talk again.
Why is "pick two of three" misleading?
The popular "pick two of three" picture is misleading because partition tolerance is not something you get to drop.
Any system that runs across more than one machine will eventually see a dropped packet, a slow link, or a dead switch. That is a partition. You cannot opt out of the network misbehaving, so P is always in play. That leaves a real choice of only two letters, C or A, and only while a partition lasts.
This is why "CA" is not a meaningful operating point. A single-node database is trivially consistent and available, but the moment it is distributed, partitions can happen and the CA label stops describing anything real. Brewer made this point himself in his 2012 retrospective. When the network is healthy, which is most of the time, a well-built system gives you both consistency and availability. You pay the CAP tax only during the rare partition.
When should you not lean on the CAP theorem?
Reach past CAP whenever the question is about normal operation rather than partitions, because CAP says nothing about the healthy case.
- Latency trade-offs. CAP ignores the cost of staying consistent when there is no partition. Keeping replicas in sync adds round trips. The PACELC model extends CAP to cover this, adding "else, latency or consistency" for the no-partition case. Use PACELC when response time is the concern.
- Tunable systems. Many stores let you choose consistency per request, so a single CP or AP label is too coarse. DynamoDB defaults to eventually consistent reads and offers strongly consistent reads with one flag. Cassandra sets consistency per query. The same cluster moves along the spectrum depending on configuration.
- Picking a database. Do not choose a datastore on its CAP letter alone. The label hides replication strategy, conflict handling, and latency, which matter more in practice. Martin Kleppmann's 2015 critique argues the CAP definitions are too narrow to guide real design and reasons about delay sensitivity instead.
| Choice under partition | Reads return | You give up | Example systems |
|---|---|---|---|
| CP (consistency) | Current data or an error | Availability | etcd, ZooKeeper, HBase |
| AP (availability) | A response, possibly stale | Consistency | Cassandra, DynamoDB, Riak |
| CA (no partition) | Both, while healthy | Meaningless once distributed | single-node databases |
How do real systems apply CAP?
Production datastores sit on a clear side of the choice, though tunable ones blur the line.
- etcd is CP. Its docs guarantee linearizable reads and writes by default through the Raft consensus protocol. When it loses a quorum during a partition, it stops accepting writes rather than serving divergent data.
- Apache Cassandra is AP. The official guarantees page states plainly that Cassandra chooses availability and partition tolerance, and that a response is not guaranteed to hold the most recent write. Per-query consistency levels let you pull it toward stronger consistency when you need to.
- Amazon DynamoDB leans AP, following the 2007 Dynamo paper that traded strong consistency for availability. Reads are eventually consistent by default, with strongly consistent reads available per operation.
- ZooKeeper and HBase are usually classed CP, since they favor consistency through quorums. ZooKeeper does allow stale reads by default, a reminder that these labels simplify reality.
The pattern holds across all of them. Coordination systems that must never lie pick CP and accept downtime during partitions. High-traffic stores that must always answer pick AP and reconcile inconsistencies afterward.
For the primary sources, see Brewer's CAP Twelve Years Later, the Gilbert and Lynch proof, and the Apache Cassandra guarantees.
Keep Reading
- Consistent Hashing. The Dynamo design that popularized AP datastores is built on the consistent hashing ring described here.
