𝗖𝗼𝗻𝘀𝗲𝗻𝘀𝘂𝘀 𝘀𝗮𝘆𝘀: “𝗟𝗲𝘁’𝘀 𝗮𝗴𝗿𝗲𝗲 𝗯𝗲𝗳𝗼𝗿𝗲 𝘄𝗲 𝗮𝗰𝘁.”
𝗖𝗥𝗗𝗧𝘀 𝘀𝗮𝘆: “𝗟𝗲𝘁’𝘀 𝗮𝗰𝘁. 𝗪𝗲’𝗹𝗹 𝗺𝗲𝗿𝗴𝗲 𝗹𝗮𝘁𝗲𝗿.” 🤯
⠀
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…

Exactly-once processing isn't the real goal.
Exactly-once effects are.
Imagine a payment service receives:
💳 Charge $100
The server charges the customer successfully.
Then it crashes before the response reaches the client.
The client sees:
"No response."…

𝗠𝗼𝘀𝘁 engineers try to fix message ordering by adding more ordering.
That can be the wrong solution. 🚨
⠀
Imagine a banking system.
A customer does:
👉 Create account
👉 Deposit $100
But the network delivers:
Deposit $100
↓
Create account
The messages are valid.…

𝗠𝗼𝘀𝘁 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 𝘁𝗵𝗶𝗻𝗸 𝗲𝘃𝗲𝗻𝘁 𝘀𝘁𝗿𝗲𝗮𝗺𝗶𝗻𝗴 𝗶𝘀 𝗮𝗯𝗼𝘂𝘁 𝗺𝗼𝘃𝗶𝗻𝗴 𝗺𝗲𝘀𝘀𝗮𝗴𝗲𝘀.
𝗧𝗵𝗮𝘁'𝘀 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗶𝗻𝘁𝗲𝗿𝗲𝘀𝘁𝗶𝗻𝗴 𝗽𝗮𝗿𝘁.
⠀
The interesting part is this:
𝗬𝗼𝘂 𝗱𝗼𝗻'𝘁 𝗳𝗼𝗿𝗴𝗲𝘁 𝘄𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝗲𝗱. 🔥
⠀
Imagine your database says:
Balance = $250
Great.
But how did it become $250?
You don't know.…