CAP Theorem
In a distributed system, you can only guarantee two of three: Consistency, Availability, and Partition tolerance. You must choose your trade-off.
What is CAP Theorem?
In short
The CAP theorem says that when a network partition splits a distributed system, you have to choose between consistency (every read sees the latest write) and availability (every request still gets an answer). You cannot keep both during the partition. Partition tolerance is not optional in a real distributed system, so the practical choice is between CP and AP.
What the CAP theorem actually says
CAP stands for three properties of a distributed system. Consistency means every read returns the most recent write, so all nodes agree on the current value. Availability means every request receives a non-error response, even if it is not the latest data. Partition tolerance means the system keeps operating even when the network drops or delays messages between nodes.
The theorem, proved by Seth Gilbert and Nancy Lynch in 2002, states that a distributed system can guarantee at most two of these three at the same time. The popular phrasing is pick two, but that wording causes most of the confusion, because the choice is not really free among three equal options.
The CAP triangle
Partition tolerance is mandatory, so the real choice runs along the right and bottom edges: CP or AP. The left edge, CA, is not reachable once the network can split.
Why partition tolerance is not a choice
In a system that runs on more than one machine, the network will eventually fail. Cables break, switches reboot, a data center link goes down, packets are delayed past their timeout. When that happens the cluster is partitioned: some nodes can no longer talk to others.
You do not get to opt out of that. A system that cannot tolerate partitions simply stops being correct the moment one occurs, which is not an option for anything running across machines. So partition tolerance is mandatory, and CAP really reduces to a single decision that you only face during a partition: do you sacrifice consistency or availability?
When there is no partition and the network is healthy, a well-built system can give you both consistency and availability at once. CAP is about the behavior during the failure, not the normal case.
CP and AP in practice
A CP system chooses consistency. During a partition it refuses to answer requests it cannot serve correctly, returning errors or timing out, rather than risk handing back stale or conflicting data. The system stays correct but some requests fail until the partition heals. This is what you want for money, inventory counts, and anything where a wrong answer is worse than no answer.
An AP system chooses availability. During a partition every node keeps answering using whatever data it has, even if that data is briefly out of date, and the divergent copies are reconciled later once nodes can talk again. The system stays up but can return stale reads. This is what you want for shopping carts, social feeds, product catalogs, and metrics, where being available matters more than every reader seeing the very latest value instantly.
The often-quoted third combination, CA, means giving up partition tolerance. That only describes a single-node system or one that assumes the network never fails, which is not a real distributed system. That is why the practical world is CP versus AP, not a free pick of any two.
Beyond CAP: latency and PACELC
CAP only describes what happens during a partition, which is rare. The PACELC extension fills the gap for normal operation: if there is a Partition, choose between Availability and Consistency, Else (when running normally) choose between Latency and Consistency.
That second half matters more day to day. Even with a healthy network, keeping every replica perfectly consistent costs round trips and therefore latency. Many systems that look AP, like Cassandra and DynamoDB, are really trading a little consistency for lower latency in the common case, not just during failures. PACELC captures that trade-off where CAP stays silent.
Where it is used in production
MongoDB
Defaults to CP: a replica set has a single primary, and during a partition the minority side steps down and rejects writes to avoid divergence.
Apache Cassandra
AP by design with tunable consistency: nodes keep serving during a partition and reconcile later, and you dial consistency per query with quorum levels.
Amazon DynamoDB
Rooted in the AP Dynamo design, with optional strongly consistent reads when you need them, so you pick the trade-off per request.
etcd and ZooKeeper
Strongly CP coordination stores built on consensus (Raft and ZAB). During a partition the side without a quorum stops serving to protect correctness.
Frequently asked questions
- Does the CAP theorem mean you can only pick two of three?
- Loosely, but the framing misleads. Partition tolerance is mandatory for any system spread across machines, because networks fail. So the real choice happens only during a partition, and it is between consistency and availability. When the network is healthy you can have both.
- Why can't a distributed system have consistency, availability, and partition tolerance all at once?
- During a network partition, two nodes that cannot talk to each other are asked for the same data. If both answer (availability), they may disagree (no consistency). If they refuse to answer unless they are sure they are current (consistency), some requests fail (no availability). You cannot have both while the partition lasts.
- What is the difference between a CP and an AP system?
- A CP system prefers correctness: during a partition it returns errors rather than possibly stale data, so some requests fail but no one reads a wrong value. An AP system prefers uptime: it keeps answering with the data each node has and reconciles differences later, so it stays available but reads can be briefly stale.
- Is CA (consistency and availability without partition tolerance) possible?
- Only on a single node or a system that assumes the network never fails, which is not a real distributed system. Once you run across machines, partitions can happen, so you must handle them. That is why practical choices are CP or AP.
- Is the CAP theorem still relevant?
- Yes, as a way to reason about failure behavior, but it is incomplete. The PACELC model extends it: during a Partition choose Availability or Consistency, Else (normally) choose Latency or Consistency. PACELC explains everyday trade-offs that CAP, which only covers the partition case, leaves out.
Learn CAP Theorem hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
See also
Related glossary terms you might want to look up next.
Consensus
The process of getting multiple nodes in a distributed system to agree on a single value. The foundation of distributed databases and coordination services.
BASE
An alternative to ACID for distributed systems: Basically Available, Soft state, Eventually consistent. Trades strong consistency for availability.
ACID
Four guarantees for database transactions: Atomicity (all or nothing), Consistency (valid states only), Isolation (no interference), Durability (changes persist).
Paxos
A family of protocols for solving consensus in unreliable networks. Famously difficult to understand but mathematically proven correct.
Raft
A consensus algorithm designed to be understandable. Uses leader election and log replication. Powers etcd (used by Kubernetes) and CockroachDB.
CQRS
Command Query Responsibility Segregation: using different models for reading and writing data. Reads and writes have different performance needs, so separate them.