CAP Theorem
The CAP theorem says that in the presence of a network partition, a distributed system cannot simultaneously guarantee Consistency (every read sees the latest write), Availability (every request gets a response), and Partition tolerance (the system continues when the network splits). In practice you choose between CP and AP when a partition occurs. This article explains the tradeoff and how it maps to real systems.
Overview
- Consistency (C): Every read returns the most recent write. All nodes see the same state at the same time (strong consistency).
- Availability (A): Every request to a non-failing node receives a non-error response. No blocking or timeout so that the service is “unavailable.”
- Partition tolerance (P): The system continues to operate when messages between nodes are lost or delayed (network partition). In real networks, partitions can happen, so P is often assumed; the real choice is CP vs AP when a partition occurs.
Example
Example 1: Partition between two replicas
Plain text[Node A] ----X---- [Node B] partition
- CP: Refuse writes or reads on one or both sides until the partition heals (e.g. require quorum). You sacrifice availability so that clients never see inconsistent data.
- AP: Allow writes and reads on both sides; data may diverge. You sacrifice strong consistency so that the system keeps responding.
Example 2: Typical classifications
| System / scenario | When partition happens | Typical choice |
|---|---|---|
| ZooKeeper / etcd | Refuse writes without quorum | CP |
| Cassandra / Dynamo-style | Accept writes on any replica | AP (eventual consistency) |
| Kafka (broker) | Leader election; some unavailability | CP-like for that partition |
| Redis Cluster | Minority partition stops accepting writes | CP-like |
Example 3: Not “3 pick 2” always
- CAP applies when there is a partition. In the normal case you can have both consistency and availability. The theorem is about the moment of partition: you relax either C or A for that period.
Core Mechanism / Behavior
- CP: Achieved by coordination (e.g. consensus, quorum). On partition, nodes that cannot form a quorum reject writes or reads so that no inconsistent state is exposed. Example: etcd rejects writes when it loses quorum.
- AP: Achieved by allowing each partition to accept operations and reconcile later (e.g. conflict resolution, last-write-wins). Example: Cassandra allows writes to any replica and uses tunable consistency (QUORUM, ONE, etc.) for reads.
Key Rules
- In practice, networks can partition, so design for P and choose how you behave under partition: CP (consistency) or AP (availability).
- “Eventually consistent” is an AP-style guarantee: the system stays available; consistency is restored when the partition heals and replicas sync.
- Use CAP to reason about system design and product claims (e.g. “strongly consistent” usually implies CP under partition), not to label a system as “only 2 of 3” in all situations.
What's Next
See Consistency Models for strong vs eventual consistency and linearizability. See Distributed Transactions for cross-service consistency patterns.