The CAP Theorem
You'll learn to
- -State the CAP theorem precisely
- -Explain why partition tolerance is not optional
Replication (previous module) creates copies of your data for safety and read scale, but it also creates a new question: what happens when replicas can't talk to each other, even briefly? That question is exactly what the CAP theorem answers.
A network partition splits the leader from a replica. Do you keep both sides serving traffic (favoring Availability), or halt the isolated side (favoring Consistency)?
In a distributed system, during a network partition, you must choose between Consistency and Availability - you cannot have both.
You run two bank branches. The network connecting them breaks (Partition). A customer deposits $1,000 at Branch A. Now Branch B is contacted for the balance. Do you: (A) show the correct $1,000 balance but pause service until sync completes (Consistency), or (B) immediately show the old balance but keep serving customers (Availability)? You just lived CAP Theorem.
CAP stands for Consistency, Availability, and Partition Tolerance. Proved by Eric Brewer in 2000, CAP Theorem states that a distributed data store can only guarantee two of these three properties simultaneously.
Consistency (C): Every read receives the most recent write or an error. All nodes see the same data at the same time. Reads are never stale.
Availability (A): Every request receives a (non-error) response, but it might not contain the most recent data. The system is always responsive.
Partition Tolerance (P): The system continues to operate despite arbitrary network partitions (messages being dropped or delayed between nodes).
The critical insight: in any real distributed system, network partitions are inevitable. Networks fail. Packets drop. Cables get cut. So P is not optional - you must tolerate partitions. This means your real choice is between C and A when a partition occurs.
- -P (Partition Tolerance) is mandatory for real distributed systems.
- -The real choice is CP vs AP during failures.
- -CP: Bank transactions, inventory management, leader elections.
- -AP: Social feeds, shopping carts, DNS, caching systems.
- -PACELC is a more nuanced extension: even without partitions, there is a Latency-Consistency tradeoff.
"We chose a CP database, so our system is always consistent." Any problem with that statement?
"No, that sounds right: CP means consistent."
"CP describes the database's behavior specifically during a network partition, not a permanent, system-wide guarantee. Outside of a partition, a CP system is both consistent and available. The theorem is about the forced trade-off in that one specific failure scenario, and even then, it's usually a per-operation choice, not a whole-system label: the same application might use strong consistency for a payment and eventual consistency for a view counter, on the very same database."