Hi Pythonistas!
Every post in Phase 2 had a tradeoff.
Caching - fresh data vs speed.
Replication - consistency vs availability.
Sharding - simplicity vs scale.
Why does every decision have a tradeoff?
Because of one fundamental rule.
CAP theorem.
Let's understand it simply.
You have two database servers.Server A and Server B.Connected by a network. Sharing the same data.
Client
↓
Server A ←→ Server B
You want three things from this system.
Three Things You Want
Consistency
Both servers always have the same data.Client reads from A or B gets the same answer.
Server A: user.name = "Afsal"
Server B: user.name = "Afsal"
Availability
System always responds.Never returns an error.Server A is slow.Client asks Server B. Server B responds. Always.
Partition Tolerance
Network between servers breaks.They can't talk to each other.System still works.Both still responding to clients.
The Problem
Network breaks between Server A and Server B.
They can't sync.
Client writes to Server A:user.name = "Afsal"
Server B doesn't know.
Client reads from Server B.
What does Server B return?
Exactly two choices.
Choice 1 - Return Error
Server B says: "I can't reach Server A.I don't know if my data is current. Error."
You get: correct data or error.
Never wrong data.
You lose: availability.
System is down during network break.
This is CP.Consistency + Partition Tolerance.
Choice 2 - Return Old Data
Server B says:"I can't reach Server A. But I'll respond with what I have."
You get: system always responds.
You lose: data might be stale.
This is AP.Availability + Partition Tolerance.
That's CAP Theorem
When network breaks:
CP → return error (consistent, sometimes unavailable)
AP → return old data (available, sometimes inconsistent)
You cannot do both.
If you return old data → not consistent.
If you return error → not available.
Pick one.Always.
Why Can't You Have Both?
Let's say you try.
Network breaks.
Client writes "Afsal" to Server A.
Server B can't sync.
Client reads from Server B.
You want Server B to:return correct data AND never return an error.
But Server B has old data.
It can either:return stale data → available, not consistent.
refuse to respond → consistent, not available.
There is no third option.
Physics prevents it.
Why Partition Tolerance Is Not Optional
Network partitions WILL happen.
Not if. When.
Cables get cut.
Routers fail.
Cloud provider has network issues.
So the real choice is always:
when partition happens — C or A?
CP → consistent but sometimes unavailable
AP → available but sometimes inconsistent
Real World Examples
Your bank - CP
Transfer money.
Network issue between servers.
Bank returns:"Service unavailable. Please try again."
Annoying.
But better than:deducting from your account.
Not adding to recipient.
Bank chooses consistency.
Instagram feed - AP
You post a photo.
Network issue.
Some friends see it.
Others don't yet.
Instagram keeps working.
No error.
Just slight delay.
Instagram chooses availability.
DNS - AP
You change your domain's IP.
Some users get old IP for hours.
DNS keeps working.
Just slightly stale.
Availability over consistency.
The Simple Rule
Wrong data is dangerous → choose CP
System being down is dangerous → choose AP
Banking, payments, inventory → CP
Social feeds, DNS, caching → AP
Now - PACELC
CAP only talks about what happens when network breaks.
PACELC asks:
what about normal times?
Even without network problems:
to be perfectly consistent servers must talk to each other before responding.
That takes time.
Slower.
OR:
respond immediately without checking other server.
Faster.
But might be slightly behind.
PACELC:
Network broken → choose Availability or Consistency
Network fine → choose Latency (speed) or Consistency
PACELC Examples
Cassandra — AP/fast:
Network broken → stays available (might return stale)
Network fine → responds fast (might be slightly behind)
Built for speed and availability.
Used by Netflix, Instagram, Discord.
HBase — CP/consistent:
Network broken → stops responding (returns error)
Network fine → waits for all nodes before responding
Built for correctness.
Used for financial data.
Connecting What You Know
Every decision in Phase 2 was CAP in disguise:
Post 8 → Caching
serve stale data (AP) vs always fresh (CP)
Post 11 → Replication
async = AP (fast, might lose data)
sync = CP (slow, no data loss)
Post 10 → Sharding
cross-shard queries = consistency problem
CAP is not a new concept.It's the theory behind every tradeoff you've already seen.
Mental Model
Partition → network break between servers
Consistency → all servers return same data
Availability → system always responds
CP → error during partition, never wrong data
AP → responds during partition, might be stale
PACELC → adds normal operation: speed vs consistency
Eventual → all servers agree eventually (AP)
Strong → all servers always agree (CP)
The One Thing to Remember
Every distributed system faces this question:
"When I'm not sure if my data is current
do I respond or refuse?"
That answer defines your system.
Respond → AP (available, eventually consistent)
Refuse → CP (consistent, sometimes unavailable)
Everything else is details.
What's Coming Next
Phase 2 is complete.
You now understand scalability:
Post 6 → Vertical vs horizontal scaling
Post 7 → Load balancing
Post 8A → Caching concepts
Post 8B → Caching under the hood
Post 9 → CDN
Post 10 → Sharding
Post 11 → Replication
Post 12 → CAP theorem & PACELC
Next
Phase 3: Storage.
How data is actually stored.
SQL vs NoSQL.
When to use which.And why the wrong choice.
can break your system at scale.
