If you've ever been in a system design interview, you've heard: "Explain the CAP theorem."
Most developers say: "You can only pick two out of three — Consistency, Availability, Partition Tolerance."
That's technically correct but misses the real point. Let me explain 👇
🔍 The Three Properties
Consistency (C)
Every read receives the most recent write.
You write balance = $100. Someone immediately reads → they get $100. Not $90. Not stale data.
Availability (A)
Every request gets a response — even if it's not the latest data.
The system never says "try later."
Partition Tolerance (P)
The system keeps working even when the network connection between nodes breaks.
🚨 The Big Misconception
Most people think you're choosing 2 from a menu:
| Choice | What happens | Practical? |
|---|---|---|
| CA | Consistent + Available, no partition handling | ❌ Not in distributed systems |
| CP | Consistent, may reject requests during partitions | ✅ Yes |
| AP | Available, may serve stale data during partitions | ✅ Yes |
Here's what people get wrong:
You don't "choose" partition tolerance. Network partitions WILL happen — they're not optional.
So the real choice is:
🎯 During a network partition, do you want Consistency or Availability?
That's it. That's CAP.
🏢 Real-World Examples
CP Systems — Choose Consistency
| System | Behavior | Best for |
|---|---|---|
| MongoDB (majority write concern) | Minority side rejects writes during partition | Financial data |
| HBase | Strong consistency, may become unavailable | Analytics platforms |
Use case: Banking — wrong data is worse than no data.
AP Systems — Choose Availability
| System | Behavior | Best for |
|---|---|---|
| Cassandra | Always accepts writes, resolves conflicts later (last-write-wins) | Social feeds |
| DynamoDB | Returns data even if slightly stale | Shopping carts |
Use case: Social media feeds — slightly stale data is totally fine.
The "CA" Myth
Traditional single-node PostgreSQL is consistent AND available — but it's not distributed.
The moment you scale to multiple nodes, you must handle partitions. CA doesn't exist in the real world of distributed systems.
🧠 Beyond CAP: The PACELC Theorem
CAP only describes behavior during partitions. But what about normal operation? That's where PACELC comes in.
PACELC says:
- If there's a Partition → choose Availability or Consistency
- Else (normal operation) → choose Latency or Consistency
| System | During Partition | Normal Operation |
|---|---|---|
| DynamoDB (PA/EL) | Available | Low Latency |
| HBase (PC/EC) | Consistent | Consistent |
| Cassandra (PA/EC) | Available | Consistent (tunable) |
This is honestly more useful than CAP for real-world system design decisions.
💡 Interview Tip
When asked about CAP in an interview, don't just recite the definition. Say something like:
"Network partitions are inevitable in distributed systems, so the real trade-off is between consistency and availability during partitions. In practice, I'd use PACELC to also consider the latency-consistency trade-off during normal operation.
For example, for a payment system I'd choose a CP system like PostgreSQL with synchronous replication. But for a social media feed, I'd choose an AP system like Cassandra where eventual consistency is acceptable."
That answer shows you understand it, not just memorized it.
Wrapping Up
- CAP isn't really "pick 2 of 3" — it's "pick C or A during a partition"
- PACELC is the practical extension you should actually use
- Real systems often have tunable consistency (Cassandra lets you choose per query)
- In interviews, always explain the trade-off, not just the acronym
If you found this useful, I write about system design and distributed systems regularly. I also maintain 119+ free browser-based dev tools for developers.
📚 Full article with more examples: swehelper.com/blog/cap-theorem
🔧 Free dev tools: swehelper.com
Top comments (0)