𝗬𝗼𝘂𝗿 𝘁𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀 𝗮𝗿𝗲 𝗹𝘆𝗶𝗻𝗴 𝘁𝗼 𝘆𝗼𝘂.
Every distributed systems engineer learns this the hard way. ⏰
⠀
Most developers believe one simple thing:
"If Event A has an earlier timestamp than Event B...
...then A happened first."
Seems obvious.
It's also wrong. 🚨…

𝗧𝘄𝗼 𝘀𝗲𝗿𝘃𝗲𝗿𝘀. 𝗧𝘄𝗼 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗰𝗹𝗼𝗰𝗸𝘀. 𝗪𝗵𝗶𝗰𝗵 𝗼𝗻𝗲 𝗶𝘀 𝗿𝗶𝗴𝗵𝘁? 🤔
⠀
Imagine this.
Server A says it's 10:00 AM.
Server B says it's 9:59 AM.
Both processed the same request.
Now answer this:
Which event happened first?
You can't tell.
And that's exactly why physical…

𝗧𝘄𝗼 𝗲𝘃𝗲𝗻𝘁𝘀 𝗰𝗮𝗻 𝗵𝗮𝗽𝗽𝗲𝗻 𝗮𝘁 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝘁𝗶𝗺𝗲.
And neither happened first.
That sounds impossible...
Until you build distributed systems. 🤯
⠀
Imagine Alice and Bob are editing the same Google Doc.
Alice updates Paragraph 1.
Bob updates Paragraph 5.
Both are offline.…

𝗠𝗼𝘀𝘁 𝗰𝗮𝗻𝗱𝗶𝗱𝗮𝘁𝗲𝘀 𝗰𝗮𝗻 𝗲𝘅𝗽𝗹𝗮𝗶𝗻 𝗥𝗮𝗳𝘁.
𝗩𝗲𝗿𝘆 𝗳𝗲𝘄 𝗰𝗮𝗻 𝗲𝘅𝗽𝗹𝗮𝗶𝗻 𝘄𝗵𝘆 𝗟𝗲𝗮𝗱𝗲𝗿 𝗘𝗹𝗲𝗰𝘁𝗶𝗼𝗻 𝗲𝘅𝗶𝘀𝘁𝘀. 🤔
That's exactly where many System Design interviews are won or lost.
⠀
Imagine five engineers working on the same project.
Everyone starts assigning tasks independently.
🚨…

𝗪𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝘄𝗵𝗲𝗻 𝘁𝘄𝗼 𝘀𝗲𝗿𝘃𝗲𝗿𝘀 𝗯𝗼𝘁𝗵 𝘀𝗮𝘆...
"I'm the leader." 👀
Without rules, distributed systems become chaos.
Raft solved this with one brilliantly simple idea.
⠀
Imagine 5 friends choosing a football captain.
👥 Alice
👥 Bob
👥 Charlie
👥 David
👥 Emma
The current…

𝗧𝗵𝗿𝗲𝗲 𝗰𝗼𝗽𝗶𝗲𝘀 𝗼𝗳 𝘆𝗼𝘂𝗿 𝗱𝗮𝘁𝗮 𝗰𝗮𝗻 𝗯𝗲 𝘄𝗼𝗿𝘀𝗲 𝘁𝗵𝗮𝗻 𝗼𝗻𝗲.
If those three copies don't agree.
⠀
Imagine your database has 3 replicas:
A → $1,000
B → $1,000
C → $1,000
A customer deposits $500.
For a short period, you might have:
A → $1,500 ✅
B → $1,000 ❌
C → $1,000…

𝗧𝗵𝗿𝗲𝗲 𝘀𝗲𝗿𝘃𝗲𝗿𝘀 𝗰𝗮𝗻 𝗵𝗮𝘃𝗲 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗱𝗮𝘁𝗮…𝗮𝗻𝗱 𝘀𝘁𝗶𝗹𝗹 𝗱𝗶𝘀𝗮𝗴𝗿𝗲𝗲.
⠀
Replication gives you multiple copies.
But it doesn't automatically give you consistency.
The real problem is much harder:
𝗪𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝗻𝗲𝘅𝘁?
⠀
Imagine 3 servers:
Server A
Server B
Server C
All start…

𝗙𝗶𝘃𝗲 𝘀𝗲𝗿𝘃𝗲𝗿𝘀 𝗱𝗶𝘀𝗮𝗴𝗿𝗲𝗲. 𝗪𝗵𝗼 𝗴𝗲𝘁𝘀 𝘁𝗼 𝗱𝗲𝗰𝗶𝗱𝗲 𝘄𝗵𝗼'𝘀 𝗿𝗶𝗴𝗵𝘁?
Imagine this:
A → X = 100
B → X = 100
C → X = 200
D → X = 100
E → ❌ crashed
Four servers are alive.
But they don't agree.
And the network can't tell you whether a server is:
👉 Dead
👉 Slow
👉 Disconnected…

𝗦𝘁𝗿𝗼𝗻𝗴 𝗰𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆 𝗶𝘀𝗻'𝘁 𝗮𝗹𝘄𝗮𝘆𝘀 𝗯𝗲𝘁𝘁𝗲𝗿. 𝗜𝘁'𝘀 𝗼𝗳𝘁𝗲𝗻 𝗷𝘂𝘀𝘁 𝗺𝗼𝗿𝗲 𝗲𝘅𝗽𝗲𝗻𝘀𝗶𝘃𝗲. ⚙️
⠀
Imagine your database has 3 replicas:
A → B → C
A user changes their name through A:
A → John ✅
But replication takes time.
For a short period:
A → John
B → Old value
C → Old value…

𝗧𝗵𝗲 𝗺𝗼𝘀𝘁 𝗲𝘅𝗽𝗲𝗻𝘀𝗶𝘃𝗲 𝘄𝗼𝗿𝗱𝘀 𝗶𝗻 𝗮 𝗱𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱 𝘀𝘆𝘀𝘁𝗲𝗺 𝗺𝗶𝗴𝗵𝘁 𝗯𝗲:
“𝗖𝗮𝗻 𝗜 𝗽𝗿𝗼𝗰𝗲𝗲𝗱?” 🚨
⠀
One server asks.
Another server checks.
A third server confirms.
Only then does the request move forward.
That sounds safe.
Until every request starts doing it. ⚙️
Latency increases.…

𝗖𝗼𝗻𝘀𝗲𝗻𝘀𝘂𝘀 𝘀𝗮𝘆𝘀: “𝗟𝗲𝘁’𝘀 𝗮𝗴𝗿𝗲𝗲 𝗯𝗲𝗳𝗼𝗿𝗲 𝘄𝗲 𝗮𝗰𝘁.”
𝗖𝗥𝗗𝗧𝘀 𝘀𝗮𝘆: “𝗟𝗲𝘁’𝘀 𝗮𝗰𝘁. 𝗪𝗲’𝗹𝗹 𝗺𝗲𝗿𝗴𝗲 𝗹𝗮𝘁𝗲𝗿.” 🤯
⠀
At first, that sounds like a recipe for data corruption.
Two replicas.
No immediate coordination.
Both changing the same data.
What could possibly go wrong? 🚨


CRDT…

𝗬𝗼𝘂𝗿 𝗿𝗲𝗽𝗹𝗶𝗰𝗮𝘀 𝗰𝗮𝗻'𝘁 𝘁𝗮𝗹𝗸 𝘁𝗼 𝗲𝗮𝗰𝗵 𝗼𝘁𝗵𝗲𝗿. 𝗗𝗼 𝘆𝗼𝘂 𝗿𝗲𝗷𝗲𝗰𝘁 𝘁𝗵𝗲 𝘂𝘀𝗲𝗿?
Or accept the write and deal with the consequences later? 🔥
⠀
A network partition happens.
Replica A is disconnected from B and C.
Then a user says:
"Update my shopping cart."
You have two choices.…

𝗔 𝗱𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱 𝘀𝘆𝘀𝘁𝗲𝗺 𝗰𝗮𝗻 𝗯𝗲 𝗰𝗼𝗺𝗽𝗹𝗲𝘁𝗲𝗹𝘆 𝗰𝗼𝗿𝗿𝗲𝗰𝘁…
𝗔𝗻𝗱 𝘀𝘁𝗶𝗹𝗹 𝗺𝗮𝗸𝗲 𝘇𝗲𝗿𝗼 𝘀𝗲𝗻𝘀𝗲 𝘁𝗼 𝘂𝘀𝗲𝗿𝘀. 🚨
⠀
Imagine opening a conversation and seeing:
Bob: “Great idea!”
No context.
No original message.
Just the reply.
Great idea about what?
The data is there.
The replicas may…

𝗠𝗼𝘀𝘁 𝗱𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱 𝘀𝘆𝘀𝘁𝗲𝗺𝘀 𝗮𝗿𝗲 𝗼𝘃𝗲𝗿-𝗰𝗼𝗼𝗿𝗱𝗶𝗻𝗮𝘁𝗲𝗱.
𝗧𝗵𝗲 𝗿𝗲𝗮𝗹 𝗺𝗶𝘀𝘁𝗮𝗸𝗲? 𝗦𝗼𝗹𝘃𝗶𝗻𝗴 𝘁𝗵𝗲 𝘄𝗿𝗼𝗻𝗴 𝗽𝗿𝗼𝗯𝗹𝗲𝗺. 🔥
⠀
We often jump straight to:
👉 Consensus
👉 Locks
👉 Transactions
👉 Global coordination
Because distributed systems are hard.
But sometimes, the real question is much…

𝗜𝗳 𝟭𝟬,𝟬𝟬𝟬 𝘀𝗲𝗿𝘃𝗲𝗿𝘀 𝗻𝗲𝗲𝗱 𝘁𝗼 𝗸𝗻𝗼𝘄 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴…
𝗗𝗼𝗻’𝘁 𝗺𝗮𝗸𝗲 𝗼𝗻𝗲 𝘀𝗲𝗿𝘃𝗲𝗿 𝗰𝗮𝗹𝗹 𝘁𝗵𝗲𝗺 𝗮𝗹𝗹. 🚨
⠀
Imagine a new configuration is deployed.
10,000 servers need to know.
The obvious solution?
One node → 10,000 messages.
Simple.
Until that “simple” design becomes your bottleneck.…

𝗬𝗼𝘂𝗿 𝗱𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱 𝘀𝘆𝘀𝘁𝗲𝗺 𝗰𝗮𝗻 𝗻𝗲𝘃𝗲𝗿 𝗸𝗻𝗼𝘄 𝗳𝗼𝗿 𝘀𝘂𝗿𝗲 𝘄𝗵𝗼 𝗶𝘀 𝗮𝗹𝗶𝘃𝗲.
𝗔𝗻𝗱 𝘁𝗵𝗮𝘁’𝘀 𝗻𝗼𝘁 𝗮 𝗯𝘂𝗴. 🚨
⠀
Imagine a cluster:
A B C D E
Then D suddenly disappears from A's view.
A says:
"D is dead."
B says:
"I can still reach D."
And D?
"I'm literally still here." ⚙️
That is…

𝗔𝗱𝗱 𝟭 𝘀𝗲𝗿𝘃𝗲𝗿.
𝗪𝗵𝘆 𝗺𝗼𝘃𝗲 𝗺𝗶𝗹𝗹𝗶𝗼𝗻𝘀 𝗼𝗳 𝗸𝗲𝘆𝘀? 🚨
That’s the problem consistent hashing was built to solve.
⠀
Imagine your system has 3 servers:
A B C
And millions of users.
A simple rule decides where each user's data lives:
hash(user_id) % number_of_servers
Fast.…

𝗧𝗵𝗲 𝗺𝗼𝘀𝘁 𝗲𝘅𝗽𝗲𝗻𝘀𝗶𝘃𝗲 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗺𝗶𝘀𝘁𝗮𝗸𝗲?
Choosing your shard key before understanding your queries. 🚨
⠀
At 10,000 users, almost any partitioning strategy works.
At 100 million?
The wrong one becomes an architectural constraint you carry for years. ⚙️
⠀
𝗖𝗼𝗻𝘀𝗶𝗱𝗲𝗿…

𝗣𝗮𝗿𝘁𝗶𝘁𝗶𝗼𝗻𝗶𝗻𝗴 𝗰𝗮𝗻 𝘀𝗰𝗮𝗹𝗲 𝘆𝗼𝘂𝗿 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲.
𝗜𝘁 𝗰𝗮𝗻 𝗮𝗹𝘀𝗼 𝗺𝗮𝗸𝗲 𝘆𝗼𝘂𝗿 𝗻𝗲𝘅𝘁 𝗼𝘂𝘁𝗮𝗴𝗲 𝗯𝗶𝗴𝗴𝗲𝗿. 🚨
⠀
Imagine 1 billion users.
So you split the data:
👉 Users A–M → Partition 1
👉 Users N–Z → Partition 2
Traffic is distributed.
The database can scale. ⚙️
Then Server A crashes.…

Distributed transactions don't solve your hardest problem.
They make you pay for certainty. 💥
⠀
Imagine transferring $100 from Alice to Bob.
Alice's balance lives on Partition A.
Bob's balance lives on Partition B.
Step 1:
Alice → -$100 ✅
Then the server…

𝗦𝗮𝗴𝗮 𝗱𝗼𝗻’𝘁 𝗽𝗿𝗲𝘃𝗲𝗻𝘁 𝗳𝗮𝗶𝗹𝘂𝗿𝗲.𝗧𝗵𝗲𝘆 𝗱𝗲𝘀𝗶𝗴𝗻 𝗳𝗼𝗿 𝗶𝘁.
⠀
Imagine an e-commerce order:
👉 Reserve inventory
👉 Charge payment
👉 Create shipment
Three services.
Three databases.
One business workflow.
Now imagine:
Inventory ✅
Payment ✅
Shipping ❌
A traditional transaction…