The Famous Triangle
The CAP theorem, formulated by Eric Brewer in 2000, states that any distributed data system can guarantee at most two of three properties:
What Each Property Really Means
Consistency (C): when you read data, you get the most recent write. Every node returns the same answer at the same time. This is about distributed nodes agreeing.
Availability (A): every request gets a non-error response, even if it's not the freshest data. The system never says "sorry, try again."
Partition Tolerance (P): the system keeps working even when network links between nodes fail or messages are lost. Network partitions are treated as a normal condition, not an exception.
The Real Story: It's Actually CP vs AP
In practice, network partitions WILL happen. Cables break, switches fail, packets drop. So partition tolerance (P) isn't optional in any real distributed system. You always get P.
The real choice is: when a partition happens, do you sacrifice consistency or availability?
Real Systems and Their Choices
| System | Choice | Why |
|---|---|---|
| Postgres (single instance) | CA (no P) | Single-node systems don't have partitions to tolerate. |
| MongoDB | CP | If primary loses quorum, it stops accepting writes. |
| HBase | CP | Strong consistency model; partitioned regions go offline. |
| Zookeeper / etcd | CP | Used for coordination; correctness over availability. |
| Cassandra | AP | Configurable, but defaults to availability and eventual consistency. |
| DynamoDB | AP (default) | Always-on shopping experiences. Strong consistency available as opt-in. |
| Riak | AP | Built for write availability under all conditions. |
The Common Misunderstanding
People often think "system X is CP all the time, system Y is AP all the time." That's not quite right.
The CAP theorem only describes behavior during partitions. When the network is healthy, even CP systems are fully available, and AP systems are fully consistent. The trade-off only shows up at the moment a partition happens.
This insight led to the PACELC theorem, an extension: If there's a Partition (P), choose between Availability and Consistency. Else (E), choose between Latency and Consistency.
Latency matters even in healthy systems. Strong consistency requires synchronous coordination across nodes, which adds latency. Eventual consistency is fast but stale. So even without partitions, you're trading speed for correctness.
How to Use CAP in Practice
When picking a database or designing a distributed system, ask:
Can my product tolerate stale data? Social feeds, search indexes, analytics: yes. Bank balances, ticket inventory, pricing: no.
Can my product tolerate downtime? Shopping carts, login systems: never. Internal admin tools: maybe.
How much latency is acceptable? Strong consistency adds round trips. If response time matters more than perfect freshness, eventual consistency wins.
The right answer is usually different per data type within the same product. User profiles can be eventually consistent. Money transfers must be strongly consistent. Use the right tool per use case.
The One Thing to Remember
CAP is not really about picking 2 of 3. It's about what your system does when the network breaks. Most modern distributed systems must tolerate partitions, so you're really choosing between consistency (CP) and availability (AP) under failure. Understanding that trade-off shapes every architectural decision after it.