⚖️ CAP Theorem – Explained Simply
The CAP Theorem, also known as Brewer’s Theorem, is a fundamental principle in distributed system design that states:
A distributed system can only guarantee two out of three properties at the same time:
Consistency (C), Availability (A), and Partition Tolerance (P).
🔺 The Three Pillars of CAP:
| Property | Meaning |
|---|---|
| Consistency (C) | Every read receives the most recent write or an error. All nodes return the same data. |
| Availability (A) | Every request receives a non-error response, even if it's not the most recent. System remains responsive. |
| Partition Tolerance (P) | The system continues to operate despite network partitions (i.e., communication breakdowns between nodes). |
💡 The Core Idea:
| Model Type | Guarantees | Sacrifices |
|---|---|---|
| CA | Consistency + Availability | No Partition Tolerance (works only if network is always reliable — unrealistic in real world) |
| CP | Consistency + Partition Tolerance | Gives up availability during network failures |
| AP | Availability + Partition Tolerance | May serve stale data (sacrifices strong consistency) |
🔁 Example Systems by Type:
| Model | Real-World Systems | Behavior |
|---|---|---|
| CP | HBase, MongoDB (in strong mode), Zookeeper | Sacrifices availability when partitioned |
| AP | Cassandra, DynamoDB, CouchDB | Returns data even if stale during partition |
| CA | Traditional RDBMS (on a single node) | Only possible in non-distributed systems |
🧠 Example Scenario:
If a partition occurs (e.g., a network failure):
- To remain consistent, you may have to reject some requests → low availability
- To remain available, you may allow stale or conflicting data → low consistency
🛠️ Design Implications:
- If you’re building a banking system, prefer CP (accuracy is more important than availability).
- For social media feeds, prefer AP (you can tolerate some lag in data consistency).