CAP theorem
In a distributed system you can guarantee at most two of Consistency, Availability, and Partition tolerance. Since networks partition, the real choice is CP or AP during a partition. Often misquoted as 'pick two always' — it's about behavior during partitions.
- As a mental model when designing distributed data systems.
- To reason about failover and stale-read behavior.
- As a slogan to justify sloppy design.
- For single-node systems (no partition concern).
Definition
CAP says a distributed system can't simultaneously provide Consistency (linearizable reads), Availability (every request gets a response), and Partition tolerance (works despite network splits). Because partitions happen, you choose CP (reject/return errors to stay consistent) or AP (serve stale data to stay available) during a partition.
Why it exists
It's a formal limit, not a feature. It tells engineers they can't have perfect consistency and availability across a network that can split, forcing an explicit tradeoff in distributed DB design.
How it works
During a partition, a CP system blocks writes (or returns errors) to prevent divergence; an AP system accepts writes on both sides and reconciles later. When there's no partition, you can have both C and A. PACELC extends CAP to latency tradeoffs when there's no partition.
Scaling limits
It's a theorem, not a tunable. The practical lesson: choose your per-operation consistency (linearizable, read-your-writes, etc.) and accept the availability/latency cost.
Cost shape
Conceptual. The cost is the tradeoff you choose: stronger consistency costs availability/latency during partitions.
Alternatives
- PACELC — Extends CAP to latency tradeoffs without partitions.
- Consistency models — Finer-grained choices than the binary CAP.
Failure modes
- Misreading it as 'pick two always'.
- Ignoring latency (PACELC).
- Assuming 'C' means transactional consistency (it means linearizability).