The CAP theorem states that a distributed system can simultaneously provide at most two of three guarantees:
- Consistency (C): Every read receives the most recent write or an error
- Availability (A): Every request receives a response (without guarantee it’s the most recent write)
- Partition Tolerance (P): The system continues to operate despite network partitions
The Trade-off
In practice, network partitions are inevitable in distributed systems, so the real choice becomes:
CP systems (Consistency + Partition tolerance): Sacrifice availability during partitions
- Example: Traditional relational databases with strong consistency
- Reject writes when majority quorum can’t be reached
AP systems (Availability + Partition tolerance): Sacrifice strong consistency during partitions
- Example: Dynamo, Cassandra
- Accept writes on all partitions, reconcile conflicts later using Eventual Consistency
Implications
The CAP theorem explains why systems like Dynamo choose Eventual Consistency: they prioritize availability (always accepting writes) over Strong Consistency, accepting temporary divergence that must be reconciled.
The theorem shows that “always available” and “always consistent” are fundamentally incompatible goals in the presence of network failures—you must choose which property to sacrifice when partitions occur.