As we discussed,
In distributed systems, CAP theorem is not simply about choosing any two out of three. It describes the trade-off between Consistency and Availability when a network Partition occurs.
When the network itself has failed, we can’t always guarantee both simultaneously.
What about CA?
CA means Consistency + Availability, without Partition Tolerance.
That means the system provides:
- Consistency: Every request sees a consistent/current view of the data.
- Availability: Every request receives a response.
- No Partition Tolerance: The system does not account for network partitions between nodes.
But in a real distributed system, network partitions can happen. So Partition Tolerance is generally something we need to account for, making the practical trade-off between CP and AP during a partition.
This leads us to two common approaches in distributed systems.
CP — Consistency + Partition Tolerance
A CP system prioritizes consistency when a partition occurs.
During a partition, if the system cannot guarantee that the data is consistent, it may reject or delay the request.
Network Partition
↓
Cannot guarantee consistent data
↓
Don't return potentially stale data
↓
Consistency preserved
Availability sacrificed
Enter fullscreen mode Exit fullscreen mode
The priority is:
“I’d rather fail the request than return incorrect or stale data.”
This can be useful for systems where incorrect information is worse than being temporarily unavailable.
Examples where strong consistency may be important:
- Money transfers
- Account balances
- Payment authorization
AP — Availability + Partition Tolerance
An AP system prioritizes availability when a partition occurs.
It continues responding even if some nodes might temporarily have different versions of the data.
Network Partition
↓
Nodes cannot communicate
↓
Still respond to requests
↓
Availability preserved
Consistency may temporarily suffer
Enter fullscreen mode Exit fullscreen mode
The priority becomes:
“I’d rather give the user an answer and resolve the inconsistency later.”
This can be useful when temporary inconsistency or stale data is acceptable.
Examples where temporary inconsistency may be acceptable:
- Shopping carts
- Product recommendations
- Likes
- View counts
Conclusion
As a developer, I don’t think the important part is memorizing:
“CP for this database, AP for that database.”
The more important part is understanding the trade-off.
Whenever we’re designing a distributed system, we should ask:
What should happen when our servers cannot communicate with each other?
Should we:
- Stop serving requests to protect correctness?
- Or continue serving requests and potentially return stale data?
That decision can affect the architecture of the entire system.