CAP Theorem
Every distributed system faces a tough choice: Consistency, Availability, or Partition Tolerance. The CAP theorem (also named Brewer's theorem ) says you can only have two of these three at the same time. Let’s break that down without the scary words.
The Core Idea
Imagine you have a database spread across several servers. Now, one server stops communicating with others due to a network issue.
What should the system do?
- Option 1: Stop answering until all servers agree on the same data.
- Option 2: Keep answering even if some answers are outdated.
You can’t do both at the same time. That’s the CAP theorem in action.
What Each Letter Means
- C – Consistency: Every read gets the latest data. No stale info.
- A – Availability: Every request gets a response (even if the system is under stress).
- P – Partition Tolerance: The system continues to function even if network messages are lost between servers.
Trade-Offs
| Type | What It Prioritizes | Example Databases |
|---|---|---|
| CP (Consistency + Partition Tolerance) | Keeps data correct, might refuse to respond during issues | MongoDB (strong mode), Redis, etc |
| AP (Availability + Partition Tolerance) | Always responds, but data might be slightly outdated | Cassandra, DynamoDB, CouchDB |
| CA (Consistency + Availability) | Works only when there’s no network issue (rare) | Single-node SQL databases |
Key Takeaways
- Distributed systems must handle network failures — that’s reality.
- You can’t have Consistency, Availability, and Partition Tolerance all perfect at once.
- Choose what to sacrifice based on your app’s goals.
Comments:
Please log in
to be able add comments.