What Is the CAP Theorem?
Imagine your app's database runs on two servers, one in Mumbai and one in Singapore, kept in sync. Suddenly the network link between them breaks. A user in Mumbai updates their address. A user in Singapore asks for it.
Should Singapore answer with the old address (stay available) or refuse until the link is back (stay consistent)? It can't do both. That trade-off is the CAP theorem.
🎯 Quick Answer (30-Second Read)
- C, Consistency: every read sees the latest write.
- A, Availability: every request to a working node gets a response.
- P, Partition tolerance: the system keeps running when the network between nodes breaks.
- Networks do break, so in practice P isn't optional. The real choice is C or A during a partition.
- CP systems refuse some requests to stay correct. AP systems answer everything but may return stale data.
- PACELC adds: even with no partition, you trade latency vs consistency.
The Three Properties
Note: CAP's "consistency" means linearizability (behaving like one copy). It's different from the "C" in ACID database transactions.
What Happens During a Partition
| Choice | During a partition | Good for |
|---|---|---|
| CP | Some requests fail or wait, but no one sees wrong data | Payments, bank balances, inventory counts, leader election |
| AP | Everyone gets an answer, some answers may be stale | Social feeds, likes, product catalogues, shopping carts |
Why "Pick 2 of 3" Is Misleading
The famous triangle suggests three options: CA, CP or AP. But a CA system would have to assume the network never fails, which isn't realistic for anything spread across machines. The theorem's author, Eric Brewer, wrote in 2012 that the "2 of 3" framing is misleading: partitions are rare, and when there's no partition, a system can offer both C and A.
PACELC: The Everyday Trade-off
Partitions are rare. But even on a normal day, keeping copies in sync costs time. PACELC says:
If there's a Partition, choose A or C. Else, choose Latency or Consistency.
happening?"} -->|Yes| PC{"Availability
or Consistency?"} Q -->|No, normal day| LC{"Low latency
or Consistency?"} PC --> PA["PA: answer with
possibly stale data"] PC --> PCC["PC: refuse until
consistent"] LC --> EL["EL: reply fast from
nearest copy"] LC --> EC["EC: wait for replicas
to confirm"]
Waiting for a replica in another region to confirm every write adds round-trip time. Many systems let you choose per request.
Real Databases
| System | Typical behaviour | Notes |
|---|---|---|
| Single-node Postgres / MySQL | Consistent | No partition between nodes, but the server is a single point of failure |
| Cassandra, DynamoDB | AP-leaning by default | Tunable: you can require more replicas to agree per request |
| MongoDB (default settings) | CP-leaning | Writes go to the primary; during a split without a majority, writes stop |
| etcd, ZooKeeper, Consul | CP | Built on consensus (Raft/ZAB); used for configuration and leader election |
| Google Spanner | CP, with very high availability | Uses synchronised clocks and Google's private network to make partitions rare |
Labels are simplified: many databases are tunable, and behaviour depends on settings like read/write quorum.
How to Use CAP in a System Design Interview
- Name which data needs strong consistency (money, inventory) and which can be eventually consistent (likes, views)
- Say what the user sees during a partition: an error, a retry, or slightly old data
- Mention PACELC: cross-region consistency adds latency even without failures
- Use different choices for different parts of the system
Frequently Asked Questions
Can a distributed system be CA?
Not in practice. A distributed system communicates over a network, and networks can fail. When a partition happens, the system must either stop answering some requests (keeping consistency) or answer with possibly stale data (keeping availability). CA only describes a single-node system.
Is Cassandra AP or CP?
Cassandra is usually described as AP because by default it stays available and replicas converge later. But its consistency is tunable per query: requiring a quorum of replicas for both reads and writes gives much stronger consistency, at the cost of availability during partitions.
What is the difference between CAP consistency and ACID consistency?
CAP consistency means every read returns the latest write, as if there were one copy of the data. ACID consistency means a transaction moves the database from one valid state to another, respecting rules like constraints. They are different ideas that share a name.
Conclusion
The CAP theorem says that when the network between your servers breaks, you must choose between consistency (refuse to answer) and availability (answer, possibly with stale data). Since partitions are unavoidable, the real decision is C vs A for each kind of data, plus the everyday latency vs consistency trade-off that PACELC describes.
Sources
- Eric Brewer: CAP Twelve Years Later: How the "Rules" Have Changed (2012)
- Gilbert & Lynch: Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services (2002)
- Daniel Abadi: Consistency Tradeoffs in Modern Distributed Database System Design (PACELC, 2012)
Last verified: 14 October 2026.
Related reads: Consistent Hashing Explained · PostgreSQL vs MySQL · Redis Explained · Instagram System Design
I write about system design and how real products are built. Follow on LinkedIn or X, or invite me to speak.