What is the CAP Theorem?
The CAP Theorem is a fundamental concept in distributed systems, which states that a distributed database system can only guarantee two out of the following three properties at any given time:
- Consistency
- Availability
- Partition Tolerance
This concept was introduced by Eric Brewer in 2000 and later proven formally as a theorem. It helps system architects understand the trade-offs involved when designing distributed systems.
Let’s Understand Each Term
Consistency
Every read receives the most recent write or an error. It means all nodes in the system return the same data at any given time.
Availability
Every request receives a (non-error) response – without the guarantee that it contains the most recent write.
Partition Tolerance
The system continues to operate despite network partitions (i.e., lost or delayed communication between nodes).
Why Can’t We Have All Three?
In theory, it might sound ideal to achieve all three – consistency, availability, and partition tolerance – but CAP Theorem states that under a network partition, you have to choose between consistency and availability.
Intuition Check:
Question: If two nodes in a system cannot communicate (partition), should we:
- Return the latest data only if both nodes agree? (Consistency)
- Return whatever one node has, even if it’s stale? (Availability)
Answer: You must pick one. That’s the core of the CAP theorem!
Real-World Examples of CAP Trade-Offs
1. CP System: Consistency + Partition Tolerance (No Availability)
Example: HBase
HBase prioritizes consistency. If there's a partition, the system may deny requests (i.e., it sacrifices availability) to ensure all nodes are consistent.
Suppose a user is trying to read a bank account balance. The system cannot contact the latest updated node due to a partition. It will refuse to give outdated data and instead throw an error – thus maintaining consistency at the cost of availability.
Question: Why would we prefer CP in financial systems?
Answer: Because data correctness is critical. Showing outdated balances could lead to severe issues like overdrawing.
2. AP System: Availability + Partition Tolerance (No Consistency)
Example: Couchbase, Cassandra
These databases aim for high availability. If a partition occurs, they still respond with whatever data they have – even if it's not the latest.
For example, in a social media app, if a user posts a comment, and there's a partition, another user might not see the comment immediately. But both can still use the app – it's highly available but not fully consistent.
Question: Why is this acceptable in a social media application?
Answer: Because minor delays in updates (like a missing comment for a few seconds) don’t critically affect user experience.
3. CA System: Consistency + Availability (No Partition Tolerance)
In practice, CA systems only work in single-node or tightly coupled networks where partition doesn’t occur – or is deliberately ignored.
Example: Traditional RDBMS like MySQL (in standalone mode)
These systems ensure both consistency and availability – but cannot scale across unreliable networks where partitions are expected.
Question: Is CA a valid choice in modern distributed architecture?
Answer: Not really. In today’s world, network partitions are inevitable, so modern distributed systems must handle them – making partition tolerance a must.
CAP in Modern System Design
While CAP simplifies trade-offs, real-world systems often blend properties using additional techniques:
- Eventual Consistency (used in AP systems like DynamoDB)
- Strong Consistency with replication (used in CP systems like Google Spanner)
- Consistency models can be fine-tuned per use-case (e.g., read-after-write, read-your-writes)
Summary Table
| System Type | Consistency | Availability | Partition Tolerance | Example Systems |
|---|---|---|---|---|
| CP | Yes | No (during partition) | Yes | HBase, MongoDB (in replica set) |
| AP | No | Yes | Yes | Cassandra, Couchbase |
| CA | Yes | Yes | No | MySQL (non-distributed) |
Final Thoughts
Understanding CAP theorem is essential for designing distributed systems. It teaches us that trade-offs are inevitable, and knowing when to sacrifice which property is key to building resilient and performant systems.
Key Questions for Practice
- Which type of system would you design for a real-time multiplayer game?
- How would you handle partitions in an e-commerce checkout system?
- What strategies can help balance consistency and availability?
Think through these questions to build your system design intuition!
Sign in with Google