The CAP theorem is where a lot of people get stuck in system design interviews — usually because they explain it wrong. It doesn't say "pick 2 out of 3" in an absolute way; it says something subtler about what happens when the network fails. Truly understanding it changes how you design distributed systems.
What C, A and P are
The CAP theorem deals with three properties of a distributed system:
- C — Consistency: every read sees the most recent write. All nodes agree on the current value.
- A — Availability: every request receives a response (not an error), even if it isn't the most up to date.
- P — Partition Tolerance: the system keeps working even when the network between nodes fails and they can't communicate.
Partitions are inevitable
Here is the correct interpretation: in a real distributed system, network partitions will happen — cables get cut, latency spikes, nodes become isolated. You can't "give up" P, because P isn't a choice, it's reality. So the theorem becomes: when there's a partition, you choose between C and A. Outside of partitions, you can have both.
The analogy: two bank tellers who lose contact with each other. If a customer wants to withdraw money, the teller has two options. Refuse until they reconnect and confirm the balance (chooses C — consistent, but unavailable). Or allow the withdrawal with the balance they know (chooses A — available, but risks inconsistency). You can't have both during the failure.
CP vs AP in practice
| Type | Prioritizes | During a partition | Example use |
|---|---|---|---|
| CP | Consistency | Refuses/blocks rather than give a wrong answer | Banking, inventory, payments |
| AP | Availability | Responds even with possibly stale data | Social feed, likes, timeline |
The choice depends on the domain. In a payments system, showing a wrong balance is unacceptable — you choose CP. In a social feed, seeing a like a few seconds late hurts no one — you choose AP, prioritizing that the screen always loads.
Strong vs eventual consistency
This leads to two consistency models. Strong consistency: after a write, every read sees the new value immediately — the intuitive behavior, but expensive in distributed systems. Eventual consistency: replicas converge to the same value "eventually", and may diverge for a short period. AP systems embrace eventual consistency.
// Eventual consistency in action:
write("profile.name", "Ana") // on node 1
read("profile.name") on node 2 -> "João" (old value, hasn't propagated yet)
... 200ms later ...
read("profile.name") on node 2 -> "Ana" (converged)CAP is not "pick 2 out of 3". It's this: since partitions are inevitable, when the network fails you'll choose between answering consistently or answering availably. Outside of a failure, you can have both.
Beyond CAP: PACELC
CAP only talks about what happens during a partition, and that's where it's worth mentioning PACELC: during a partition (P) you choose between A and C; but even without a partition (Else, E), there's a trade-off between Latency (L) and Consistency (C) — keeping everything strongly consistent costs response time. PACELC is CAP completed with the everyday, normal-operation part.
Conclusion
The CAP theorem is a lens for deciding how your system behaves under network failure. It's not about arbitrarily picking two pillars: it's about understanding that the partition calls the shots, and that the real decision is between consistency and availability at the moment of failure — and between consistency and latency the rest of the time. That decision is inseparable from how you think about scalability.