Imagine you’re running a global e-commerce platform.
A customer in Mumbai clicks “Pay Now.”
The request reaches your India region:
Everything has worked perfectly for months.
Then, during a massive sale, something goes wrong.
The network connection between Mumbai and Singapore breaks.
Now suppose the customer tries to purchase the last available item.
Mumbai says:
“Inventory = 1. I’ll sell it.”
Singapore simultaneously says:
“Inventory = 1. I’ll sell it.”
You now potentially have:
You now potentially have:
Mumbai: inventory = 0
Singapore: inventory = 0
But:
Orders created = 2
Actual items = 1Congratulations.
You’ve just encountered one of the fundamental problems of distributed systems.
This is where CAP Theorem becomes practical.
And this is also where one of the most commonly repeated explanations of CAP becomes misleading:
❌ “You can pick any two of Consistency, Availability, and Partition Tolerance.”
That’s not really how CAP should be understood.
The useful mental model is:
When a network partition happens, a distributed system must trade off strong consistency against availability.
Let’s unpack why.
What is CAP Theorem?
CAP stands for:
C — Consistency
A — Availability
P — Partition Tolerance
The theorem says that a distributed system cannot guarantee strong consistency and availability simultaneously when a network partition occurs.
The common explanation:
❌ “Pick any 2 out of 3.”
is misleading.
The more useful mental model is:
Network Partition
|
+----+----+
| |
v v
Consistency Availability
CP APWhen a partition happens, you have to make a trade-off between C and A.
1. Consistency
CAP consistency generally means linearizability.
After a successful write, subsequent reads should see that value or a newer value.
WRITE balance = ₹500
|
v
READ balance
|
v
₹500Important:
CAP Consistency is not the same as the C in ACID.
2. Availability
Availability means that every request sent to a non-failing node receives a non-error response.
During a network failure, an available system continues serving requests.
The trade-off is that the response may not reflect the latest global state.
3. Partition Tolerance
A partition occurs when distributed nodes cannot reliably communicate.
Node A Node B
DB DB
| |
XXXXXXXXXXXXXXXXXXXXXXXX
Network
PartitionNetwork failures, packet loss, latency spikes, cloud outages, and routing problems make partitions a reality.
Therefore:
Partition tolerance is not really an optional configuration in a distributed system.
CP vs AP
CP — Consistency + Partition Tolerance
During a partition, the system may reject or block some requests rather than risk inconsistent data.
Client
|
v
Node A
|
X ---- Node B
|
ERRORTypical use cases:
Financial transactions
Distributed locks
Leader election
Inventory reservation
Configuration/coordination
Examples include ZooKeeper, etcd, and appropriately configured MongoDB deployments.
AP — Availability + Partition Tolerance
During a partition, the system continues serving requests even if replicas temporarily disagree.
Node A Node B
stock = 0 stock = 1
| |
XXXXXXXXXXXXXXXXXXXXXXXX
PartitionWhen the network recovers, the system reconciles the differences.
Typical use cases:
Social feeds
Shopping carts
Large-scale analytics
Highly available applications
Examples include Apache Cassandra and systems using eventual-consistency patterns such as DynamoDB’s eventually consistent reads.
How Should Engineers Think About CAP?
Don’t simply ask:
“Is this database CP or AP?”
Instead ask:
1. What happens if the network fails?
2. Can stale data cause business damage?
3. Can two nodes safely make independent decisions?
4. Can conflicting updates be merged?
5. How much latency is acceptable?
For example:
Payment authorization → Strong consistency
Inventory reservation → Strong consistency
Social feed → Eventual consistency
Analytics dashboard → Eventual consistency
Shopping cart → Often eventual/tunable3 Key Takeaways
1. CAP does NOT mean “pick any 2 of 3.”
The important trade-off happens when a network partition occurs: Consistency vs Availability.
2. Partition tolerance is a reality.
If your application is distributed across machines or regions, network failures must be part of your design.
3. Choose consistency per business requirement.
Don’t make your entire architecture “CP” or “AP” blindly. Determine which data requires strong consistency and which data can tolerate temporary staleness.
The real question isn’t “CP or AP?”
It’s “What must remain correct when the network fails?”