← All Concepts
Distributed Systems
CAP Theorem
States that a distributed system can only guarantee two of three properties: Consistency, Availability, and Partition Tolerance.
**CAP Theorem** (Brewer's theorem): In the presence of a network partition, a distributed system must choose between Consistency and Availability.
**The three properties:**
- **Consistency (C)**: Every read receives the most recent write
- **Availability (A)**: Every request receives a response (not guaranteed to be latest)
- **Partition Tolerance (P)**: System continues operating despite network partitions
**Since network partitions are inevitable**, the real choice is between CP and AP:
- **CP systems** (HBase, MongoDB, Zookeeper): Sacrifice availability during partitions. Return error rather than stale data.
- **AP systems** (Cassandra, DynamoDB, CouchDB): Sacrifice consistency during partitions. May return stale data.
**PACELC extension:** Even without partition, there's a tradeoff between Latency and Consistency. Low-latency reads may return stale data.
**In practice:** Most systems are tunable. DynamoDB lets you choose strong or eventual consistency per request.
Common Use Cases
- Choosing between SQL (CP) and NoSQL (AP) databases
- Designing replication strategy
- Deciding consistency level per API endpoint
- Understanding system behavior during failures
Advantages
- +Framework for understanding distributed system tradeoffs
- +Helps make informed architecture decisions
- +Clarifies what guarantees a system provides
- +Guides database and replication choices
Disadvantages
- -Oversimplifies - real systems are more nuanced
- -Network partitions are rare - day-to-day tradeoff is latency vs consistency
- -Does not address all failure modes
- -Can lead to premature optimization if applied dogmatically