CAP Theorem
A principle that states a distributed data store cannot simultaneously provide more than two out of three guarantees: Consistency, Availability, and Partition Tolerance.
Detailed Explanation
Consistency: every read receives the most recent write. Availability: every request receives a response (not necessarily the latest). Partition Tolerance: the system continues to operate despite network failures between nodes. In the real world, network failures *will* happen, so distributed systems must choose between Consistency (CP) or Availability (AP) during a failure.
Quick Summary
CAP says that during a network partition, a distributed system can have either strict consistency or full availability, not both. In practice, every real distributed system is constantly making this tradeoff at finer grain.
Key Takeaways
- Partition tolerance is non-negotiable in a real distributed system, networks fail. So the real choice is C vs A *during* a partition.
- CP systems (Spanner, etcd, ZooKeeper) refuse some requests to preserve consistency.
- AP systems (Cassandra, DynamoDB defaults) keep serving, possibly with stale data, through partitions.
- PACELC extends CAP: even without partitions, systems trade Latency vs. Consistency.
- Most modern databases let you tune consistency per query, so the choice isn't system-wide.
When to use it
- Choosing a database: payments → CP, social feed → AP, both reasonable.
- Configuring read consistency in DynamoDB or Cassandra (strong vs. eventual) per workload.
- Designing failover behavior: do you fail to a replica with possible data loss, or refuse writes until the primary returns?
- Reasoning about microservice availability when a downstream dependency partitions.
Common Mistakes
- Treating CAP as "pick any two" instead of "during a partition, pick C or A."
- Assuming relational databases are immune; a single-node DB just hides the question by not being distributed.
- Picking AP without thinking through the user-visible consequences of stale reads.
- Picking CP without monitoring availability, the system can drop writes silently when quorum fails.
CAP Theorem, Frequently Asked
Can a system be CA (consistent + available, no P)?
Only if there's no network partition possible, i.e., a single node. The moment you have multiple nodes communicating, partition tolerance must be assumed, and you're choosing between C and A during partitions.
What's PACELC?
An extension of CAP that says: during a Partition, choose Availability or Consistency; Else (normal operation), choose Latency or Consistency. It captures the everyday tradeoff CAP misses, that even healthy distributed systems pay latency for strong consistency.