Chapter: Trade Offs

content/sd/hook.en.mdx

@@ -1,28 +1,27 @@
 ---
-title: "A New Snag!"
-description: Montu hits the limits of distributed systems, a teaser for the CAP and PACELC theorems.
+title: "Fresh Trouble!"
 tags:
-  - Distributed Systems
-  - CAP Theorem
-  - PACELC Theorem
-  - System Trade-offs
+  - Database Selection
+  - SQL vs NoSQL
+  - Database Trade-offs
+  - Database Architecture
 ---
 
-A few days later. Everything's running smoothly now. No more complaints about BiralTube's speed, and the fear of servers crashing has died down too. But Montu's restless founder brain still wouldn't leave him alone.
+Montu's nagging doubts had finally vanished. The truth was a bit of a bitter pill to swallow, but he accepted that he couldn't just have everything he wanted.
 
-Sipping coffee one night, Montu asked himself, "I worked so hard building a distributed system, did the data partitioning, the replication, all of it, so why isn't everything perfect? When I push for more speed, syncing data across every server lags behind (Replication Lag), but when I try to sync every server instantly, the system slows to a crawl. Isn't there some magic solution where the speed is blazing fast, the same data lives everywhere, AND I get 100% uptime?"
+Afternoon had faded into night. Montu got out of his chair, ready to head home, when Boltu Bhai casually tossed out a simple question, "By the way, Montu, what kind of databases are you using for BiralTube? SQL or NoSQL? Or something else entirely?"
 
-![hook](/images/sd/replication/7.png)
+Montu's eyes went wide. "Wait, what's all that, Bhai? I just set up everything using a single MySQL database! Do databases have different breeds or something?"
 
-Frustrated, the next morning Montu called Boltu again. Boltu heard it all and burst out laughing.
+![trade-off-hook](/images/sd/trade-offs/7.png)
 
-"You goof, you think the universe just hands you everything at once? You've stepped into the world of distributed systems, and here, the real game is 'trade-offs', giving up one thing to gain another. Come over to my place this afternoon. I'll teach you two theories, **CAP Theorem** and **PACELC Theorem**, and once you hear them, you'll see for yourself exactly why thinking you can grab 'everything at once' in software engineering is just plain foolish!"
+Boltu Bhai burst out laughing. "To find that out, you'll have to come back another day. For now, go home and get some sleep!"
 
 To be continued...
 
 ---
 
-Want updates when the next chapter drops? Subscribe to the newsletter:
+Want updates on the next chapter? Subscribe to the newsletter:
 
 <SubscribeModal lang="en" />
 

content/sd/hook.mdx

@@ -1,23 +1,23 @@
 ---
 title: নতুন বিপত্তি!
 tags:
-  - Distributed Systems
-  - CAP Theorem
-  - PACELC Theorem
-  - System Trade-offs
+  - Database Selection
+  - SQL vs NoSQL
+  - Database Trade-offs
+  - Database Architecture
 ---
 
-কয়েকদিন পর। সবকিছু এখন ঠিকঠাক চলছে। বিড়ালটিউবের স্পিড নিয়ে আর কোনো অভিযোগ নেই, সার্ভার ডাউন হওয়ার ভয়ও কমেছে। কিন্তু মন্টুর স্টার্টআপ ফাউন্ডার মনের খুঁতখুঁতে ভাবটা কিছুতেই যাচ্ছে না।
+মন্টুর মনের খুঁতখুঁতানি পুরোপুরি কেটে গেছে এখন। সত্য একটু তেতো হলেও সে মেনে নিয়েছে যে, চাইলেই সে সবকিছু পাবে না।
 
-রাতে কফি খেতে খেতে মন্টু নিজেকেই প্রশ্ন করল, “আমি এত কষ্ট করে ডিস্ট্রিবিউটেড সিস্টেম বানালাম, ডাটা পার্টিশন, রেপ্লিকেশন সব করলাম, তবু কেন সব পারফেক্ট হচ্ছে না? স্পিড বাড়াতে গেলে সব সার্ভারে ডাটা সিঙ্ক হতে দেরি হয় (Replication Lag), আবার সব সার্ভারে ইনস্ট্যান্ট ডাটা সিঙ্ক করতে গেলে সিস্টেম স্লো হয়ে যায়। এমন কোনো ম্যাজিক সলিউশন কি নেই, যেখানে স্পিডও রকেটের মতো হবে, সব জায়গায় একই ডাটা থাকবে, আবার ১০০% আপটাইমও পাওয়া যাবে?”
+বিকেল গড়িয়ে রাত হয়ে গেছে। মন্টু চেয়ার ছেড়ে উঠে বিদায় নিতে যাবে, ঠিক তখনই বল্টু ভাই উদাস মনে মন্টুকে সহজ সরল একটা প্রশ্ন করলেন, “আচ্ছা মন্টু, তুই কোন কোন ধরনের ডাটাবেস ইউজ করছিস বিড়ালটিউবের জন্য? SQL নাকি NoSQL? নাকি অন্য কোনো ধরনের?”
 
-![hook](/images/sd/replication/7.png)
+মন্টুর চোখ কপালে উঠল। “আরেহ! এসব আবার কী ভাই? আমি তো এক MySQL ডাটাবেস দিয়েই সবকিছু সেটআপ করেছি। ডাটাবেসেরও আবার জাত-পাত আছে নাকি?”
 
-হতাশ হয়ে পরদিন সকালে মন্টু আবার বল্টু ভাইকে ফোন দিল। সব শুনে বল্টু ভাই হো হো করে হেসে উঠলেন।
+![trade-off-hook](/images/sd/trade-offs/7.png)
 
-“আরে গাধা, চাইলেই কি আর দুনিয়ার সব একসাথে পাওয়া যায়? তুই ডিস্ট্রিবিউটেড সিস্টেমের দুনিয়ায় পা দিয়েছিস, এখানে 'ট্রেড-অফ' (Trade-off) বা একটা পাওয়ার জন্য আরেকটা ছাড় দেওয়াটাই হলো আসল খেলা। আজ বিকেলে আমার এখানে আয়। তোকে এমন দুটো থিওরি বোঝাবো, **CAP Theorem** আর **PACELC Theorem**, যেটা শোনার পর তুই নিজেই বুঝবি কেন সফটওয়্যার ইঞ্জিনিয়ারিংয়ে 'সবকিছু একসাথে' পাওয়ার চিন্তা করাটা স্রেফ বোকামি!”
+বল্টু ভাই হো হো করে হেসে উঠলেন। “সেটা জানতে হলে তোকে আরেকদিন আসতে হবে। আজ যা, গিয়ে ঘুমা!”
 
-চলবে...
+চলবে…
 
 ---
 

content/sd/meta.en.json

@@ -11,6 +11,7 @@
     "caching",
     "data-partitioning",
     "replication",
+    "trade-offs",
     "hook"
   ]
 }

content/sd/meta.json

@@ -11,6 +11,7 @@
     "caching",
     "data-partitioning",
     "replication",
+    "trade-offs",
     "hook"
   ]
 }

content/sd/trade-offs/ap-system.en.mdx

@@ -0,0 +1,37 @@
+---
+title: "When Uptime is Everything"
+description: "The Like Button Dilemma"
+tags:
+  - AP Systems
+  - Availability
+  - Partition Tolerance
+  - Eventual Consistency
+  - High Availability Architecture
+  - Social Media System Design
+---
+
+Boltu Bhai laughed. "It's great to have flawless math when money is involved, but does the whole world run on bank ledgers? Take your BiralTube, for example."
+
+Montu sat up straight.
+
+"Imagine a cute cat video goes absolutely viral on BiralTube. Thousands of people are watching and smashing the like button every second. Suddenly, a Network Partition (P) hits between your Dhaka server and your Singapore server. Neither can sync data with the other."
+
+"Okay," Montu nodded along.
+
+"Now, what happens if you built BiralTube as a CP system, just like the bank? Since the Singapore server can't send like updates to the Dhaka server, it will just stop accepting requests altogether. When a user hits 'Like', the screen will spit out an error: 'Action failed' or 'Service unavailable'. Think about it—if your system crashes just because someone tried to like or watch a cat video, are your users going to stick around?"
+
+Montu shook his head instantly. "No way! They'd delete their accounts and run for the hills."
+
+"Exactly," Boltu Bhai explained. "That's why for social media or video platforms, Availability (A) is vastly more critical than Consistency (C). When the network drops, your system should just accept the like instead of throwing an error. Sure, a user in Dhaka might see 50,000 likes on the video, while a user in Singapore sees 49,990 likes. That 10-like difference is a data mismatch, or inconsistency. But the user doesn't care! The video is playing, the like button works—the user is happy!"
+
+![ap-system](/images/sd/trade-offs/5.png)
+
+Montu's eyes lit up. "I get it! Since it doesn't matter if the data isn't 100% perfectly accurate, but it's an absolute disaster if the system goes down or freezes, BiralTube has to be an **AP system**."
+
+Boltu Bhai took a sip of his tea and said, "Spot on. System design is all about making the right architectural decisions based on your specific business needs. If you need the data to be flawless at all times, you go with CP. If you don't strictly need the absolute latest data instantly, you go with AP."
+
+Montu breathed a huge sigh of relief. "Thank God! So that means as long as the internet is working fine, I have nothing to worry about. My system is 100% perfect then!"
+
+Boltu Bhai burst into laughter. "Who told you that, rookie? Even when the internet is working flawlessly, you still have to make another massive trade-off. Enter the PACELC theorem!"
+
+Montu was stunned. "Another new theorem? What on earth is that?"

content/sd/trade-offs/ap-system.mdx

@@ -0,0 +1,37 @@
+---
+title: "যখন Availability বেশি জরুরি"
+description: "Like Count"
+tags:
+  - AP Systems
+  - Availability
+  - Partition Tolerance
+  - Eventual Consistency
+  - High Availability Architecture
+  - Social Media System Design
+---
+
+বল্টু ভাই হাসলেন। “টাকার ক্ষেত্রে হিসাব ঠিক থাকা ভালো, কিন্তু সব জায়গায় কি আর টাকার হিসাব চলে? তোর বিড়ালটিউবের কথাই ধর।”
+
+মন্টু সোজা হয়ে বসল।
+
+“ধর, বিড়ালটিউবে একটা কিউট বিড়ালের ভিডিও ভাইরাল হয়েছে। প্রতি সেকেন্ডে হাজার হাজার মানুষ ভিডিওটা দেখছে আর লাইক দিচ্ছে। এখন ঢাকার সার্ভার আর সিঙ্গাপুরের সার্ভারের মধ্যে নেটওয়ার্ক পার্টিশন (P) হলো। কেউ কারও সাথে ডাটা সিঙ্ক করতে পারছে না।”
+
+“আচ্ছা,” মন্টু সায় দিল।
+
+“এখন তুই যদি বিড়ালটিউবকে ব্যাংকের মতো CP সিস্টেম বানাস, তাহলে কী হবে? সিঙ্গাপুরের সার্ভার যেহেতু ঢাকার সার্ভারকে লাইকের আপডেট পাঠাতে পারছে না, সে রিকোয়েস্ট নেওয়াই বন্ধ করে দেবে। ইউজার লাইক বাটনে চাপ দিলেই স্ক্রিনে এরর দেখাবে, 'Action failed' বা 'Service unavailable'। তুই চিন্তা কর, একটা বিড়ালের ভিডিওতে লাইক দিতে গিয়ে বা ভিডিও দেখতে গিয়ে যদি সিস্টেম ডাউন দেখায়, ইউজাররা কি তোর প্ল্যাটফর্মে থাকবে?”
+
+মন্টু সাথে সাথে মাথা নাড়ল, “কক্ষনো না! একাউন্ট ডিলিট করে পালাবে।”
+
+“এই জন্যই,” বল্টু ভাই বুঝিয়ে বললেন, “সোশ্যাল মিডিয়া বা ভিডিও প্ল্যাটফর্মগুলোতে Consistency (C)-র চেয়ে Availability (A) অনেক বেশি দরকারি। নেটওয়ার্ক কাটা পড়লে তোর সিস্টেম এরর না দেখিয়ে লাইকটা নিয়ে নেবে। হয়তো ঢাকার ইউজার দেখবে ভিডিওতে ৫০,০০০ লাইক, আর সিঙ্গাপুরের ইউজার দেখবে ৪৯,৯৯০ লাইক। এই যে ১০টা লাইকের পার্থক্য, এটাকে বলে ডাটা মিসম্যাচ বা ইনকনসিস্টেন্সি। কিন্তু এতে ইউজারের কোনো মাথা ব্যথা নেই। ভিডিও চলছে, লাইক দেওয়া যাচ্ছে, ইউজার তাতেই খুশি!”
+
+![ap-system](/images/sd/trade-offs/5.png)
+
+মন্টুর চোখ চকচক করে উঠল, “বুঝতে পেরেছি! যেহেতু এখানে ডাটা ১০০% একুরেট না হলেও সমস্যা নেই, কিন্তু সিস্টেম কোনোভাবেই ডাউন হওয়া বা থমকে থাকা যাবে না, তাই বিড়ালটিউব হলো একটা **AP সিস্টেম**।”
+
+বল্টু ভাই চায়ের কাপে একটা চুমুক দিয়ে বললেন, “একদম তাই। সিস্টেম ডিজাইন হলো তোর বিজনেসের ওপর ভিত্তি করে সঠিক ডিসিশন নেওয়া। সবসময় ডাটা ঠিকঠাক দেখাতে হলে CP নিবি, আর একদম লেটেস্ট ডাটা সবসময় দরকার না হলে AP নিবি।”
+
+মন্টু স্বস্তির নিশ্বাস ফেলল, “যাক বাবা! তার মানে ইন্টারনেট ঠিক থাকলে আমার কোনো চিন্তা নাই, তখন আমার সিস্টেম ১০০% পারফেক্ট!”
+
+বল্টু ভাই হো হো করে হেসে উঠলেন। “কে বলেছে রে গাধা? ইন্টারনেট ঠিক থাকলেও তোকে আরেকটা বিশাল ট্রেড-অফ করতে হবে। সেটা হলো PACELC থিওরি!”
+
+মন্টু অবাক, “আবার নতুন থিওরি? সেটা আবার কী?”

content/sd/trade-offs/cap.en.mdx

@@ -0,0 +1,39 @@
+---
+title: "CAP Theorem"
+description: "Two Passengers, One Seat"
+tags:
+  - CAP Theorem
+  - Consistency
+  - Availability
+  - Partition Tolerance
+  - Network Partitions
+  - Distributed Systems Trade-offs
+---
+
+Sipping his tea, Boltu Bhai slipped into storyteller mode. "Imagine, Montu, you start an intercity bus service called 'Redline'. You have 10 buses traveling from Dhaka to Chittagong every day. Each bus has 50 seats, giving you 500 seats in total. You also have 5 ticket counters spread across Dhaka. Now, all 5 counter managers need to know if there are any seats left before selling a ticket. So, you create a WhatsApp group for them. The rule is simple: whenever someone sells a ticket, they drop a message in the group, and everyone else updates their own ledgers. Once 500 tickets are sold for the day, the counters close."
+
+— "Wow, brilliant idea! Zero hassle."
+
+— "The hassle is just beginning! One day, the nationwide internet goes down completely. Your managers' WhatsApp stops working. Nobody can tell anyone else how many tickets they've sold. As the owner of the bus company, you only have two options to handle this crisis."
+
+![partition](/images/sd/trade-offs/2.png)
+
+— "What are they?"
+
+— "Option one: you give your managers strict orders that the moment WhatsApp goes down, ticket sales stop instantly! Nobody sells a single ticket until they can verify the inventory with the other counters."
+
+— "If I do that, my business is doomed! Sending customers away will ruin our reputation. What's the other option?"
+
+— "Option two: you tell your managers to screw the ledger. Internet or no internet, do not turn any customers away! Keep selling whatever tickets you have, and we'll deal with the mess later."
+
+— "But Bhai, if they can't talk to each other, what if they accidentally sell 700 or 800 tickets instead of 500? The customers will literally tear me apart when they board the bus and find no seats!"
+
+Montu went completely quiet. He finally understood the problem.
+
+Boltu Bhai put a hand on Montu's shoulder. "This loss of internet that completely severed communication between your counters? In distributed systems, this is called a **Network Partition**. And in the real world, networks _will_ fail at some point. Accepting this harsh reality and preparing for it is known as **Partition Tolerance (P)**."
+
+Montu nodded slowly. "Got it, Bhai."
+
+— "Whenever the counters lose connection, as the owner, you are forced to choose one of those two options. You can choose to halt all sales to prevent double booking, ensuring your data and ledgers remain absolutely flawless, this system property is called **Consistency (C)**. On the other hand, if you want your counters to remain open no matter what so that no customer goes home empty-handed, you have to keep selling at the risk of messing up the ledgers, this is called **Availability (A)**."
+
+Boltu Bhai took another sip of his tea and continued, "Even if you have multiple counters, as long as they can communicate with each other perfectly, you can maintain both Consistency and Availability. The real problem only starts when that communication is actually severed. During that Network Partition, you simply cannot guarantee both flawless Consistency and total Availability at the exact same time. You have to make a sacrifice on one side. That is the fundamental truth of the CAP Theorem."