CAP Theorem Explained: Simple Terms & Interview Prep
Understand the CAP theorem (Consistency, Availability, Partition Tolerance) in layman's terms. Master distributed database tradeoffs for your next data engineering interview.
CAP Theorem Explained: Simple Terms & Interview Prep
CAP Theorem
The CAP Theorem is a fundamental concept in distributed systems and a must-know topic for Data Engineering, Backend, and System Design interviews.
🧠 What is CAP Theorem? (The Elevator Pitch)
“In a distributed system, you can only guarantee 2 out of 3 properties at any given time: Consistency, Availability, and Partition Tolerance.”
Proposed by Eric Brewer in 2000 (hence also called Brewer’s Theorem).
🔺 The CAP Triangle
1
2
3
4
5
6
7
8
9
10
11
C (Consistency)
/\
/ \
/ \
CP / \ CA
/ ❌ \
/ Can't have \
/ all three! \
/________*_______\
P (Partition A (Availability)
Tolerance) AP
📘 The 3 Properties Explained
🔹 C — Consistency
“Every read receives the most recent write or an error.”
1
2
3
4
5
6
7
Client writes X = 5
│
┌─────────┴─────────┐
│ Node A: X = 5 │──sync──▶│ Node B: X = 5 │
└───────────────────┘ └───────────────────┘
✅ Client reads from ANY node → always gets X = 5
- All nodes see the same data at the same time
- Like a single database experience — no stale reads
- Memory aid: “Everyone agrees on the answer.”
🔹 A — Availability
“Every request receives a response (not an error), even if it’s not the most recent data.”
1
2
3
4
5
6
7
8
9
10
11
12
Client sends request
│
┌────┴────┐
│ Node A │ ──── ✅ Responds (maybe stale data)
│ (UP) │
└─────────┘
│ Node B │ ──── ✅ Also responds
│ (UP) │
└─────────┘
❌ NEVER returns: "Service Unavailable" or timeout
- System is always responsive — no downtime
- May return slightly outdated data, but always returns something
- Memory aid: “Always answers the phone, even if the info is old.”
🔹 P — Partition Tolerance
“The system continues to operate even if communication between nodes breaks.”
1
2
3
4
5
6
┌─────────┐ ✂️ NETWORK ┌─────────┐
│ Node A │ ────── PARTITION ──────── │ Node B │
│ X = 5 │ (can't talk!) │ X = 3 │
└─────────┘ └─────────┘
System MUST still function despite this break!
- Network failures will happen in distributed systems (it’s not “if” but “when”)
- The system doesn’t crash — it handles the split
- Memory aid: “Survives a broken phone line between nodes.”
⚡ Why Can’t You Have All 3?
Here’s the intuitive proof — imagine a network partition happens:
1
2
3
4
┌─────────┐ ✂️ BROKEN ┌─────────┐
│ Node A │ ─────────────────────── │ Node B │
│ │ (can't sync!) │ │
└─────────┘ └─────────┘
Now you have a choice:
| Choice | What Happens | You Sacrifice |
|---|---|---|
| Keep Consistency | Node B refuses to respond until it syncs with A | ❌ Availability (B is down) |
| Keep Availability | Node B responds with its own (possibly stale) data | ❌ Consistency (A ≠ B) |
| Ignore Partition | Only works if partition never happens | ❌ Partition Tolerance (unrealistic) |
💡 “You can’t have a system that always responds (A), always returns the latest data (C), AND handles network splits (P) — pick two.”
🎯 The 3 Combinations
Since Partition Tolerance is mandatory in real distributed systems (networks WILL fail), the real choice is:
CP or AP? (CA is mostly theoretical)
🔹 CP — Consistency + Partition Tolerance
“I’d rather give no answer than a wrong answer.”
1
2
3
4
5
6
7
8
┌─────────┐ ✂️ PARTITION ┌─────────┐
│ Node A │ ──────────────── │ Node B │
│ X = 5 │ │ X = 3 │
└────┬────┘ └────┬────┘
│ │
Client reads ❌ BLOCKED!
from A → X = 5 "Sorry, can't guarantee
consistency. Try later."
- ✅ Data is always correct
- ❌ System may be unavailable during partitions
- Use cases: Financial systems, banking, inventory management
| CP Databases | Description |
|---|---|
| MongoDB (default config) | Strong consistency, may block during partition |
| HBase | Consistent reads/writes on Hadoop |
| Redis (cluster) | Can prefer consistency |
| Zookeeper | Coordination service — consistency is critical |
| etcd | Distributed key-value store (used by Kubernetes) |
- Interview tip: “Choose CP when wrong data is worse than no data — like bank balances or seat booking.”
🔹 AP — Availability + Partition Tolerance
“I’d rather give a possibly stale answer than no answer.”
1
2
3
4
5
6
7
8
┌─────────┐ ✂️ PARTITION ┌─────────┐
│ Node A │ ──────────────── │ Node B │
│ X = 5 │ │ X = 3 │
└────┬────┘ └────┬────┘
│ │
Client reads Client reads
from A → X = 5 ✅ from B → X = 3 ✅
(stale but available!)
- ✅ System is always available
- ❌ Data may be inconsistent (temporarily)
- Relies on eventual consistency — nodes will sync later
- Use cases: Social media feeds, shopping carts, DNS, CDNs
| AP Databases | Description |
|---|---|
| Cassandra | Always available, eventually consistent |
| DynamoDB | AWS managed, highly available |
| CouchDB | Availability-first document store |
| Riak | Distributed key-value, AP by design |
| Cosmos DB (configurable) | Can be tuned for AP |
- Interview tip: “Choose AP when downtime is worse than stale data — like social media likes or product catalog.”
🔹 CA — Consistency + Availability (⚠️ Theoretical)
“I want correct data AND 100% uptime — but I’m pretending network failures don’t exist.”
1
2
3
4
5
6
┌─────────┐ ✅ PERFECT ┌─────────┐
│ Node A │ ── CONNECTION ── │ Node B │
│ X = 5 │ (no partition) │ X = 5 │
└─────────┘ └─────────┘
✅ Consistent + Available... but only when network is perfect
- ⚠️ Not realistic in distributed systems — partitions WILL happen
- Only possible in single-node systems (traditional RDBMS)
| CA Systems | Description |
|---|---|
| PostgreSQL (single node) | Consistent + Available, no partition handling |
| MySQL (single node) | Same — no distribution = no partition problem |
| Oracle (single node) | Traditional RDBMS |
- Interview tip: “CA only works when there’s no distribution. The moment you go multi-node, you MUST handle partitions (P), so CA breaks.”
🗺️ The CAP Database Map
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
CONSISTENCY
│
┌────────────┼────────────┐
│ │ │
│ MongoDB │ │
│ HBase │ MySQL* │
│ Redis │ PostgreSQL*│
│ Zookeeper│ Oracle* │
│ etcd │ │
│ │ │
│ (CP) │ (CA*) │
│ │ *single │
│ │ node │
PARTITION───────┼────────────── AVAILABILITY
TOLERANCE │
│ │
│ Cassandra │
│ DynamoDB │
│ CouchDB │
│ Riak │
│ │
│ (AP) │
│ │
└────────────┘
🔄 Eventual Consistency — The AP Companion
Since AP systems sacrifice consistency, they rely on eventual consistency:
“If no new updates are made, eventually all nodes will have the same data.”
1
2
3
4
5
6
7
Time T0 (Write): Time T1 (Syncing): Time T2 (Consistent):
Node A: X = 5 Node A: X = 5 Node A: X = 5
Node B: X = 3 (stale) Node B: X = 5 (syncing) Node B: X = 5 ✅
Node C: X = 3 (stale) Node C: X = 3 (waiting) Node C: X = 5 ✅
❌ Inconsistent ⏳ Converging ✅ Eventually Consistent
Consistency Spectrum
1
2
3
4
5
6
7
8
9
Strong ◄──────────────────────────────────────────────► Eventual
Consistency Consistency
│ Linearizable │ Sequential │ Causal │ Read-your- │ Eventual │
│ │ │ │ writes │ │
│ (Strictest)│ │ │ │(Loosest) │
│ │ │ │ │ │
│ Zookeeper │ etcd │ │ DynamoDB │Cassandra │
│ Spanner │ │ │ │ CouchDB │
🆕 PACELC Theorem — The Extended CAP
“CAP only talks about what happens during a partition. But what about when things are normal?”
PACELC says:
1
2
3
4
5
6
7
8
9
10
11
12
13
IF (Partition happens):
Choose between Availability (A) and Consistency (C)
ELSE (normal operation):
Choose between Latency (L) and Consistency (C)
P A C / E L C
│ │ │ │ │ │
│ │ │ │ │ └── Consistency
│ │ │ │ └──── Latency
│ │ │ └────── Else (no partition)
│ │ └────────── Consistency
│ └──────────── Availability
└────────────── Partition
| System | During Partition (PAC) | Else (ELC) | Full Classification |
|---|---|---|---|
| Cassandra | PA (Available) | EL (Low Latency) | PA/EL |
| DynamoDB | PA (Available) | EL (Low Latency) | PA/EL |
| MongoDB | PC (Consistent) | EC (Consistent) | PC/EC |
| HBase | PC (Consistent) | EC (Consistent) | PC/EC |
| Cosmos DB | PA (configurable) | EL (configurable) | PA/EL (tunable) |
- Interview tip: “PACELC extends CAP by adding the latency vs consistency tradeoff during normal operations. It’s a more complete picture.”
🎯 Real-World Scenario Decisions
| Scenario | Choose | Why |
|---|---|---|
| Bank account balance | CP | Wrong balance = disaster. Better to block than show wrong amount |
| Flight seat booking | CP | Can’t sell the same seat twice |
| Social media likes | AP | Showing 999 vs 1000 likes temporarily is fine |
| Shopping cart | AP | Cart should always work; sync later |
| DNS (Domain Name System) | AP | Must always resolve; slight staleness is OK |
| Stock trading | CP | Trades must be accurate and ordered |
| Chat messages | AP | Message delivery > perfect ordering |
| Inventory count | CP | Can’t oversell; block if unsure |
🎤 Top Interview Questions & Answers
| # | Question | Best Answer |
|---|---|---|
| 1 | What is CAP theorem? | In a distributed system, you can guarantee only 2 of 3: Consistency, Availability, Partition Tolerance |
| 2 | Can you have all 3? | No. During a network partition, you must choose between C and A |
| 3 | Is CA realistic? | Only for single-node systems. In distributed systems, P is mandatory, so real choice is CP vs AP |
| 4 | What does Cassandra choose? | AP — always available, eventually consistent |
| 5 | What does MongoDB choose? | CP — prefers consistency, may be unavailable during partition |
| 6 | What is eventual consistency? | All nodes will converge to the same value eventually, if no new writes occur |
| 7 | When would you pick CP? | When wrong data is worse than no data (banking, inventory, booking) |
| 8 | When would you pick AP? | When downtime is worse than stale data (social media, DNS, carts) |
| 9 | What is PACELC? | Extension of CAP: during Partition choose A/C, Else choose Latency/Consistency |
| 10 | Is CAP a strict rule? | It’s a spectrum — systems can be tuned. E.g., Cosmos DB lets you configure consistency levels |
🏁 Quick Revision Cheat Sheet
1
2
3
4
5
6
7
8
9
10
11
12
13
14
🔺 CAP = Consistency + Availability + Partition Tolerance (pick 2)
🌐 P is mandatory in distributed systems → Real choice: CP vs AP
CP → "Correct or nothing" → Banks, Bookings → MongoDB, HBase, Zookeeper
AP → "Always respond" → Social, Carts, DNS → Cassandra, DynamoDB, CouchDB
CA → "Only single-node" → Traditional RDBMS → PostgreSQL*, MySQL* (*single node)
🔄 Eventual Consistency = AP systems sync data over time
📐 PACELC = CAP + (Else: Latency vs Consistency)
Memory Aid:
C = "Everyone sees the SAME thing"
A = "Everyone gets a RESPONSE"
P = "Survives a NETWORK BREAK"
💡 Pro Interview Tip: When asked about CAP, don’t just define it — give a real-world analogy:
“Imagine two bank branches (Node A & B) with the phone line cut (partition). A customer deposits ₹10,000 at Branch A. Now Branch B has two options:
- CP: Block all queries about that account until the phone line is restored (consistent but unavailable)
- AP: Show the old balance and sync later (available but inconsistent)
You can’t do both — that’s CAP theorem in action.”
This post is licensed under CC BY 4.0 by the author.