What is the CAP theorem, in simple words?
The CAP theorem says that when a network partition splits a distributed system, it must choose between consistency (every read sees the latest write or gets an error) and availability (every request gets a non-error response, possibly stale). Partitions can't be ruled out, so the real choice is CP or AP during a partition.
Explain it simply
Two friends, Aman in Delhi and Neha in Bengaluru, run a small ticket counter for a college fest. Each keeps a copy of the seat list and they sync over the phone after every sale.
One day the phone line goes dead. That is a partition: the two copies cannot talk.
A customer walks up to Aman and asks for seat A1. Aman has two choices:
- Refuse to sell until the line comes back, because Neha may have already sold A1. The data stays correct, but the counter is not available. That is choosing consistency (CP).
- Sell anyway from his own copy. The customer is served, but Neha might sell A1 too, and someone ends up with a double booking. That is choosing availability (AP).
He cannot do both while the line is down. That is the whole theorem.
Example
Normal day (no partition): both C and A are possible.
Partition between Node 1 and Node 2:
write(x = 5) arrives at Node 1
read(x) arrives at Node 2, which still has x = 3
CP system: Node 2 returns an error or waits -> correct, not available
AP system: Node 2 returns x = 3 -> available, staleHow it works
The three letters, precisely:
- C, Consistency: every read returns the most recent write, as if there were a single copy of the data. (This is linearizability, not the "C" in ACID.)
- A, Availability: every request to a working node gets a non-error response, without a guarantee that it is the latest data.
- P, Partition tolerance: the system keeps working even when messages between nodes are lost or delayed.
In any system spread across machines, networks do fail, so partition tolerance is not optional. "Pick two of three" is misleading; the honest version is: when a partition happens, choose C or A. When there is no partition, you can have both.
Typical choices
- CP: systems where wrong data is worse than an error. Bank balances, seat inventory, leader election. ZooKeeper and etcd behave this way, and so do databases configured to require a majority (quorum) for reads and writes.
- AP: systems where showing slightly old data is fine. Social media like counts, product reviews, shopping cart contents, DNS. Cassandra and DynamoDB are often run this way and reconcile later (eventual consistency).
Many databases let you tune this per request, for example by choosing how many replicas must confirm a read or write.
Real-world use
During an IRCTC Tatkal rush, the final seat allocation must never sell one berth twice, so that path favours consistency, even if some users see errors and retry. But the "trains between stations" search page can show slightly outdated availability; it favours availability and speed. One product, two different choices for two different features.
Common mistakes
- Saying "we picked CA". In a distributed system you cannot give up partition tolerance; that only describes a single machine.
- Confusing CAP consistency with ACID consistency. They mean different things.
- Treating CAP as a label for a whole database forever. Many systems are tunable, and the trade-off is really per operation.
- Forgetting latency. Even without a partition, stronger consistency usually means waiting for more replicas.
What to say in the interview
"CAP says that in a distributed system, when a network partition happens, you must choose between consistency, where every read sees the latest write or fails, and availability, where every request gets a response that may be stale. Since partitions can't be avoided, the choice is really CP or AP during a failure. I'd pick CP for things like payments or seat booking where double-spending is unacceptable, and AP for things like feeds, likes or carts where slightly stale data is fine and the system should keep responding. Many databases let you tune this with quorum settings."
Follow-up questions
- What is eventual consistency?
- What is the PACELC theorem?
- How do quorum reads and writes (R + W > N) give strong consistency?
- Is a single-node PostgreSQL CP, AP or neither?
Go deeper
Read these once the basics above feel easy.
PACELC extends CAP: if there is a Partition, choose Availability or Consistency; Else, choose Latency or Consistency. It captures the everyday trade-off. With N replicas, writing to W and reading from R where R + W > N means every read overlaps at least one replica that has the latest write, which gives stronger consistency at the cost of latency and availability.
AP systems need conflict resolution when partitions heal: last-write-wins (simple but can lose data), version vectors to detect concurrent updates, or CRDTs that merge automatically. CP systems typically use consensus protocols like Raft or Paxos, which need a majority of nodes reachable to make progress, so a minority side of a partition stops accepting writes.