CAP Theorem
During a network partition, a distributed system can guarantee at most two of Consistency, Availability, and Partition Tolerance.
Overview
CAP theorem states that during a network partition, a distributed system can guarantee at most two of three properties at once: Consistency (every node sees the same data), Availability (every request gets a response), and Partition Tolerance (the system keeps working despite the network being split). Since partitions are a real, unavoidable fact of networked systems, the actual choice engineers face in practice is between C and A — not whether to have P at all.
Why It Exists
CAP formalizes something engineers observed empirically: during a genuine network split, a distributed database physically cannot both guarantee every node has an identical view of the data and guarantee every node keeps answering requests, because reconciling those views requires communication — which is exactly what's broken during the partition. CAP exists to make that trade-off explicit and force a deliberate choice, instead of one discovered by accident during an actual outage.
Real World Example
Two data-center nodes handling writes lose their network link to each other. A CP system chooses Consistency: nodes that can't confirm agreement with the rest of the cluster refuse writes (or reads) rather than risk serving stale or conflicting data — the application sees errors for the duration of the partition. An AP system chooses Availability: every node keeps accepting reads and writes independently, and the two sides reconcile once the network heals — the application keeps working, but might briefly see inconsistent data across the split.
The Three Letters — and the Choice You Actually Make
Consistency (C)
Every node returns the same, most-recent data for a given read, no matter which node answers the request.
Availability (A)
Every request to a non-failing node receives a response — it may not be the most recent data, but the system never simply refuses to answer.
Partition Tolerance (P)
The system continues operating despite an arbitrary number of messages being dropped or delayed between nodes — i.e. despite the network splitting.
Why You Only Really Choose Between C and A
Network partitions — a cut cable, a failed switch, a cross-region latency spike — are a physical reality for any system spanning more than one machine. A system that isn't partition-tolerant isn't a real distributed system. In practice, P is a given, and the actual design decision is CP vs. AP.
Diagram
The choice CAP actually forces only applies once a partition happens
Network partition occurs
Node A and Node B can't communicate
Choose Consistency (CP)
reject requests that can't be confirmed cluster-wide
Choose Availability (AP)
keep answering independently, reconcile later
Common Mistakes
Treating CAP as 'pick any 2 of 3' during normal operation
Why: CAP's trade-off only actually applies during a network partition. When the network is healthy, a well-designed system can offer both C and A at the same time — this is exactly the gap PACELC (the next chapter) extends CAP to address.
Fix: Understand CAP describes partition-time behavior specifically, not a permanent, always-active 2-out-of-3 restriction.
Assuming Partition Tolerance is optional to skip
Why: Network partitions are a physical reality for any system with more than one machine — a system that isn't partition-tolerant simply isn't a real distributed system, so in practice you're always choosing between CP and AP, never CA.
Fix: Treat P as a given for any multi-node system, and focus the real design decision on C vs. A.
Assuming every part of a system needs the same CAP choice
Why: A single application often has some data that should be CP (inventory counts, payments) and other data that should be AP (activity feeds, view counts) — treating the whole system as one monolithic CAP choice oversimplifies real architecture.
Fix: Make the C-vs-A choice per data type or service, not once for the entire system.
Interview Questions
State CAP theorem in plain terms.
During a network partition, a distributed system can guarantee at most two of Consistency, Availability, and Partition Tolerance — it can't guarantee all three at once.
Why isn't 'CA' (Consistency + Availability, no Partition Tolerance) a real option for a genuinely distributed system?
Network partitions are a physical inevitability once a system spans more than one machine — cables get cut, switches fail, regions lose connectivity. A system that assumes partitions never happen isn't built to survive one, so 'CA' really describes a single-node system, not a distributed one. Any real distributed system must be partition-tolerant, which is why the practical choice is CP vs. AP.
You're designing a system with both a payments ledger and a public activity feed. How would CAP thinking shape the architecture differently for each?
The payments ledger should be CP: during a partition, it should refuse to process a payment it can't confirm consistently across nodes, rather than risk double-processing or losing money. The activity feed should be AP: during a partition, it's far better to keep showing content — even slightly stale — than to show users an error. This is a case where the C-vs-A decision is made per service, not once for the whole system.
Production Best Practices
Do
✓Make the C-vs-A decision deliberately, per data type or service, based on the real cost of being wrong versus being unavailable.
✓Design explicitly for what happens during a partition — don't leave it as undefined behavior.
✓Revisit PACELC (next chapter) to also account for the far more common non-partitioned case.
Don't
✗Don't treat CAP as an always-active 2-of-3 restriction — it specifically describes partition-time behavior.
✗Don't assume a single CAP choice fits every kind of data in your system.
✗Don't pretend network partitions won't happen just because they're rare — design for them anyway.
Comparison
| Behavior During a Partition | Example Systems | Best For | |
|---|---|---|---|
| CP (Consistency) | Refuses requests it can't confirm | MongoDB (default), HBase, Google Spanner | Payments, inventory, anything requiring correctness |
| AP (Availability) | Keeps answering, reconciles later | Cassandra, DynamoDB, CouchDB | Activity feeds, counts, session data |