As developers, we often assume that distributed systems can provide everything at once: perfectly consistent data, high availability, and resilience to network failures. Unfortunately, distributed systems don't work like that.
This is where the CAP Theorem comes in, one of the most fundamental concepts in distributed computing.
What Is the CAP Theorem?
Proposed by computer scientist Eric Brewer, the CAP Theorem states that a distributed system can guarantee only two of the following three properties simultaneously:
- Consistency (C)
- Availability (A)
- Partition Tolerance (P)
When a network partition occurs, you must choose between consistency and availability.
Consistency
Consistency means every node sees the same data at the same time.
If you update a user's account balance, every server should immediately return the updated value.
From the user's perspective:
- Read after write works correctly
- No stale data
- Single source of truth
Availability
Availability means every request receives a response, even if some servers are experiencing issues.
The response might not contain the most recent data, but the system remains operational.
Examples:
- Social media feeds: If User X updates their profile info, it's just fine if User Y sees the old info for a few minutes.
- Product recommendations
- Content Platforms
- Analytics dashboards
- Review Sites (Yelp etc.)
These systems often prioritize availability over strict consistency.
We can basically ask ourselves "Would it be catastrophic if users briefly saw inconsistent data?" If the answer is yes, choose consistency. If not, choose availability[1]
Partition Tolerance - Not Optional
A partition happens when nodes cannot communicate because of network failures."Partition Tolerance” is the the ability of a distributed system to continue operating even when a partition occurs.
In modern cloud environments, partitions are not hypothetical events.
They happen because of:
- Network outages
- Region failures
- Router issues
- Infrastructure maintenance
Since partitions are unavoidable, most distributed systems must support partition tolerance. Because you cannot prevent hardware failures or router crashes.The systems should not be affected by network partitions.
Therefore, any distributed system must be partition-tolerant.
A Real-World Example: The ATM
Imagine you have $1,000 in your bank account and two ATMs connected to different bank servers.
You withdraw $200 from the first ATM, but a network failure prevents the second server from receiving the update 🫣 The second ATM still shows your balance as $1,000.
Now, you try to withdraw another $900 from the second ATM.
- Consistency (CP): The ATM rejects the transaction because it cannot verify your current balance. The system sacrifices availability to protect data consistency.
- Availability (AP): The ATM continues processing transactions using its outdated balance, potentially allowing you to withdraw more money than you actually have.
Real banking systems use additional safeguards to prevent such situations.
This example illustrates the fundamental CAP trade-off: when a network partition occurs, a system may need to reject or delay requests to maintain consistency, or continue responding despite the risk of serving outdated data.
The Real Trade-off
The CAP Theorem becomes important when a partition occurs.
At that moment you must decide:
CP Systems
Consistency + Partition Tolerance
The system rejects or delays requests to ensure data remains correct.
Examples:
- Banking transactions
- Inventory management
- Financial systems
Correctness matters more than availability.
AP Systems
Availability + Partition Tolerance
The system continues serving requests even if some nodes have outdated information.
Examples:
- Social networks
- Messaging systems
- Content platforms
Availability matters more than immediate consistency.
What About CA Systems?
Technically, CA systems exist only when partitions never happen.
In real distributed environments, partitions are inevitable.
This is why most cloud-native systems end up choosing either CP or AP behavior during failures.
CAP in Modern Databases
Different databases make different trade-offs:
| Database | Typical Preference |
|---|---|
| MongoDB | CP |
| Apache Cassandra | AP |
| DynamoDB | AP-oriented |
| PostgreSQL (single node) | CA-like |
| CockroachDB | CP |
Understanding these trade-offs helps architects choose the right database for their workload.
Why Developers Still Need CAP
Many developers learn CAP Theorem during interviews or reviewing the interview questions and then forget about it😀
But CAP influences real-world decisions:
- Designing microservices
- Choosing databases
- Building global applications
- Handling outages
- Architecting cloud-native systems
Whenever someone says, "Why can't we just keep everything available and perfectly consistent?", they are usually running into the limitations described by CAP.
I think CAP Theorem is not like a database rule. It is a reminder that distributed systems require trade-offs.
As systems scale across regions, clouds, and continents, understanding those trade-offs becomes more important than memorizing any specific technology.
Resources & Further Reading
[1]- Cap Theorem
Understanding CAP Theorem: Basics and Real-World Examples
Image credit: My original design - Cover Image
Top comments (0)