এই প্রথম সেশন, যেখানে প্রতিটা solution একটা নতুন সমস্যা তৈরি করে। Real distributed system এ স্বাগতম।
০০ যে প্রশ্নগুলোর উত্তর খুঁজবো
প্রতিটা প্রশ্নের উত্তর জানার পর আপনি বুঝবেন replication, replication এর cost, আর source of truth এর মতো critical concept।
- ১ এখনো একটাই database। আমি আসলে দুটো জিনিস protect করতে চাইছি, সেগুলো কী?
- ২ একাধিক copy রাখার basic idea টা কী?
- ৩ Read আর Write আলাদা করব কেন? শুধু safety এর জন্য copy রাখলে হয় না?
- ৪ Replica যদি read serve করতে পারে, তাহলে সবকিছু replica থেকেই কেন না?
- ৫ Primary তো এখনো down হয়ে যেতে পারে, তখন কী হবে?
- ৬ ৫টা replica থাকলেও কি backup দরকার?
- ৭ User write করার পরের মুহূর্তেই read করল, কী হবে?
- ৮ System এখন কেমন? এখনো কোনো single point of failure আছে?
০১ এখনো database একটাই। আসলে আমরা কী protect করছি?
সেশন ০২ শেষ। আমরা যা পেয়েছি, তাতে database এখনো SPOF। Database down হলে পুরো system down। আরো ভয়ংকর: disk crash করলে data চিরতরে হারিয়ে যায়।
আমরা আসলে দুটো জিনিস achieve করতে চাচ্ছি:
- Durability: মেশিন crash করলেও data ঠিকঠাক থাকে (information হারায় না)।
- Availability: মেশিন down হলেও service চালু থাকে (user serve হতে থাকে)।
এই দুটো একই শোনালেও আসলে আলাদা।
- Daily backup durability দেয় (গতকালের data recover করা যায়), কিন্তু availability না (restore চলাকালীন service down)।
- Live replica availability দেয় (instant failover), কিন্তু দুই মেশিন একসাথে পুড়ে গেলে সব data হারিয়ে যায়।
দুটোই দরকার। দুটো আলাদা আলাদা সমস্যার সমাধান দেয়।
০২ একাধিক copy রাখার basic idea?
লাইব্রেরির গল্প
ধরুন একটা লাইব্রেরিতে প্রতিটা বইয়ের একটা করেই কপি আছে।
- একজন বই issue করলে অন্য কেউ আর সেটা পড়তে পারে না।
- লাইব্রেরি পুড়ে গেলে সব বই শেষ।
- পরীক্ষার সময় ১০০ জন একই কপির জন্য ভিড় করে।
এই সমস্যা সমাধানে ২টা কাজ করা যায়:
- ফটোকপি বানানো (Replica): বেশি reader এর জন্য বেশি কপি, শুধু original কপি নয়।
- আলাদা building এ master কপি রাখা (Backup): এক building পুড়লেও অন্যটায় বই safe থাকে।
Database এর জন্য ঠিক এটাই করব।
Database Replication: Primary-Replica মডেল
Multiple machine এ database এর একাধিক copy রাখা। একটা down হলেও অন্যগুলোতে data থাকে।
পুরোনো নাম: Master-Slave। আধুনিক নাম: Primary-Replica।
০৩ Read আর write আলাদা করব কেন?
বেশিরভাগ application এ write এর চেয়ে read হয় অনেক বেশি:
- Tweet: একবার লেখা হয়, হাজার জন পড়ে।
- Order: একবার place হয়, multiple party (user, warehouse, shipping) পড়ে।
- Post: একবার তৈরি হয়, শত শত মানুষ দেখে।
সাধারণ read:write ratio থাকে 80:20 বা 95:5। তাই এক Primary আর অনেক Replica মিলে বিপুল read traffic সামলাতে পারে।
এতে যা পাই:
- Reads scale: একাধিক replica অ্যাড করার কারণে read scale হয়।
- Replica down survive: এক replica down হলে অন্য replica থেকে read করা যায়।
- Primary down survive: Primary down হলে একটা replica কে নতুন primary বানানো হয় (Failover)।
- Heavy query isolate: analytics, report এসব replica তে চালান, primary free রাখুন।
- Latency কমে: geographic অবস্থান অনুযায়ী user নিজের location এর কাছাকাছি replica থেকে data fetch করে, ফলে latency কমে।
০৪ Replica যদি read serve করতে পারে, সব কিছু কেন replica থেকে না?
এটাই হলো catch: Replication Lag।
Primary থেকে Replica তে data copy হতে কিছু সময় লাগে। এই delay কেই বলে Replication Lag।
সাধারণত কয়েক millisecond, কখনো কয়েক second, network খারাপ হলে minute পর্যন্ত।
উদাহরণ:
Step 1: আপনি Facebook প্রোফাইল পিকচার বদলালেন। Update গেল Primary DB তে। Primary তে নতুন ছবি। Step 2: Primary শুরু করল changes কে replica তে copy করতে। Step 3: replica তে Copy শেষের আগেই আপনি page refresh মারলেন। Read গেল Replica তে (এখনো পুরোনো ছবি)। Step 4: পুরোনো ছবি দেখে ভাবলেন update fail। আবার "update" click করলেন। ডাবল আপডেট অপারেশন চললো।
Eventual Consistency vs Strong Consistency
Primary DB এর changes গুলো replica তে copy শেষ হয়ে গেলে replica গুলো eventually same data পায়। কিন্তু replication চলাকালীন মধ্যবর্তী কোনো একটা moment এ আলাদা আলাদা replica আলাদা data দেখাতে পারে।
প্রতিটা read সর্বশেষ write থেকেই data পায়, যে replica থেকেই read করা হোক না কেন। Synchronous Replication এর মাধ্যমে এটা achieve করা যায়। সবগুলো replica তে write confirm হওয়ার পরেই user কে done বলা হয়। তাই write operation slow, কিন্তু safer।
| Eventual Consistency | Strong Consistency |
|---|---|
| Fast | Slower |
| Scale করা সহজ | Scale করা কঠিন |
| Stale read হতে পারে | সবসময় fresh |
| Like, view count, comments এর জন্য উপযোগী | Bank, inventory, payment এর জন্য বাধ্যতামূলক |
এই concept টা পরে আরো গভীরে explore করব (CAP Theorem এর সময়)। এখনকার জন্য মনে রাখুন: replication এর cost আছে, এটা free নয়।
০৫ Primary তো এখনো ডাউন হয়ে যেতে পারে, তখন কী হবে?
Primary down হয়ে গেলে write operation বন্ধ হয়ে যায়। এর fix হলো Failover: কোনো একটা replica কে promote করে নতুন primary বানানো।
Failover কঠিন কেন?
- Primary সত্যিই down হয়েছে, এটা কীভাবে বুঝবেন? হয়তো slow চলছে। হয়তো network connection broken। Primary alive থাকতেই replica কে promote করলে Split Brain হয়: দুই primary, দুটোই write নিচ্ছে, data corruption।
- হারিয়ে যাওয়া write (Lost writes): Primary যে write accept করেছিল কিন্তু replica তে copy হয়নি, সেই replica কে primary তে promote করলে ওই write গুলো হারিয়ে যায়।
- Failover এ সময় লাগে: কয়েক second থেকে minute পর্যন্ত। এই সময় application write accept করতে পারে না।
আধুনিক system এ Raft, Paxos, Zookeeper এই সমস্যার সমাধান দেয়। নামগুলো জানা থাকুক, বিস্তারিত পরে।
০৬ ৫টা Replica থাকলেও কি Backup দরকার?
হ্যাঁ। এই জায়গাটা অনেক engineer কেই confusion এ ফেলে দেয়।
| Replication | Backup |
|---|---|
| Real-time copy | Point-in-time snapshot |
| Machine failure থেকে রক্ষা | Human mistake, corruption, malware থেকে রক্ষা |
| Live, active machine এ থাকে | Cold storage এ stored (S3, tape) |
| Recovery দ্রুত (seconds/minutes) | Recovery ধীর (ঘণ্টা পর্যন্ত) |
একটা ভয়ংকর গল্প
একজন developer ভুল করে primary তে এটা type করল:
DELETE FROM users;
কী হলো?
- Primary DB সব users delete করল।
- Replication এই DELETE সব replica তে পাঠিয়ে দিল।
- কয়েক second এর মধ্যেই সব মেশিনে আর কোনো user নেই।
- Replication ভুলটাকে সব জায়গায় ছড়িয়ে দিল।
এখানে backup ই একমাত্র escape gate। গত রাতের snapshot থেকে data restore করুন।
Replication রক্ষা করে hardware failure থেকে। Backup রক্ষা করে software mistake, human error, আর corruption থেকে। দুটোই important।
০৭ User write করার পরের মুহূর্তেই read করল, কী হবে?
User cart এ item add করল (Primary তে write)। তারপর refresh করল (Replica থেকে read, যেখানে lag আছে)।
সমস্যা:
- User cart এ add করা item দেখতে পায় না।
- সমস্যাটা গুরুতর: হয়তো আবার add করবে (duplicate), বা site ছেড়ে চলে যাবে।
সবাই যেভাবে ভাবে:
“DB এর বদলে cache use করি”, এটা একটা বিপজ্জনক চিন্তা।
- Cache volatile: Redis restart হলে cart data হারিয়ে যায়।
- “আগে cache এ অ্যাড করি, পরে DB তে sync করব”; কিন্তু কখন? Checkout যদি ততক্ষণে হয়ে যায়? Sync fail করলে?
এটা multiple sources of truth তৈরি করে, যা System Design এর সবচেয়ে বড় ভুলগুলোর একটা।
সমাধান: ৩টা option
যে user এইমাত্র write করেছে, তার পরের reads কিছু সময়ের জন্য Primary তে route করুন (যেমন ৩০ second)। বাকি user রা replica থেকেই read করবে।
User A cart এ add → Primary তে write। পরের ৩০ second User A এর reads → Primary তে। ৩০ second পর Replicas catch up → আবার Replica তে।
এটাই সবচেয়ে common solution।
DB এর উপরে cache রাখুন, DB কে replace করবেন না।
Cart এ add: ১. Primary DB তে write (source of truth) ২. Cache এও write (fast read layer) Cart read: ১. Cache দেখুন আগে (fresh, fast) ২. Miss হলে Replica থেকে ৩. তাও না পেলে Primary থেকে
Cache হলো optimization, source of truth নয়।
User কে “done” বলার আগে অন্তত একটা replica confirm করা পর্যন্ত wait করুন।
- Write slow হয়।
- Primary write এর পরেই immediately down হলেও data loss হয় না।
- তবে মনে রাখুন, বেশিরভাগ database এ default setup থাকে Asynchronous Replication: Primary write এর সাথে সাথেই user কে জানিয়ে দেওয়া হয়, আর replication background এ চলতে থাকে।
Source of Truth: critical concept
Data এর official, authoritative version যেখানে থাকে, সেটাই Source of Truth। বাকি সব (cache, replica, search index) হলো শুধু copy।
System design করার সময় সবসময় একটা প্রশ্ন করুন: এখানে আমার source of truth কোনটা?
Cart problem এ source of truth হলো Database। Cache হলো speed এর জন্য copy। Replica হলো read এর জন্য copy।
“Source of truth কোনটা”, এটা এক বাক্যে answer দিতে না পারলে বুঝে নিন design এ সমস্যা আছে।
০৮ System এখন কেমন? এখনো ব্রোকেন পয়েন্ট আছে?
এখন পর্যন্ত কি কি ঠিক করা হলো?
- Database availability - Replicas রিড হ্যান্ডেল করে। Primary ডাউন হলেই failover।
- Data durability - Permanent Backup, data loss থেকে রক্ষা।
- Read scaling - বেশি replica যোগ করলে massive read traffic replica database থেকেই handle হয়ে যায়।
নতুন যেসব সমস্যা (Trade-offs)
- Replication Lag - eventual consistency, stale read এর সম্ভাবনা।
- Failover Complexity - split brain, lost writes, detection problem (primary আসলেই ডাউন হয়েছে কিনা)।
- Cost - বেশি মেশিন, বেশি মনিটরিং।
যা এখনো বাকি
- দূরের user এখনো হাই লেটেন্সি পাবে। Database যত fast ই হোক, ভৌগোলিকভাবে দূরের user হাই লেটেন্সি ফেস করবে।
- Write এখনো এক মেশিন থেকে। Write traffic বাড়লে bottleneck তৈরি হবে।
- প্রতি request ডাটা লোড করছে database থেকে। Cache layer নেই।
০৯ মগজে প্রেশার দিন
আগে নিজে ভাবুন। তারপর দেখুন সবাই যেভাবে ভাবে, কেন সেটা ভুল, আর সঠিক চিন্তা কী।
উত্তর দেখুন আগে নিজে ভাবুন
সবাই যেভাবে ভাবে
“Main goal হলো read আর write load balance করা। একাধিক read node নিজের resource দিয়ে load handle করে।”
এই চিন্তা ঠিক direction এ, কিন্তু সব কারণ cover করছে না।
সঠিক উত্তর: ৫টা কারণ
- Read আর write load আলাদা: Primary শুধু write handle করবে।
- Reads horizontally scale: বেশি replica অ্যাড করার কারণে read load scale হবে।
- Geographic distribution: replica একাধিক হওয়ায় আমরা user এর location এর উপর base করে আলাদা আলাদা location এ replica server বসাতে পারি। এতে user নিজের কাছাকাছি replica use করে, latency কমে।
- Heavy query isolate: Analytics, report এর মতো heavy কিন্তু non-urgent query গুলো replica তে পাঠান। Primary কে শুধু time-sensitive request handle এর জন্য ব্যবহার করুন। (এটা industry pattern, কিন্তু প্রায়ই miss হয়ে যায়।)
- Failover candidate: primary down হলে replica নতুন primary হতে পারে।
Stale data এর cost: বাস্তবে বেশিরভাগ read এর জন্য কিছুটা staleness acceptable। কিন্তু কোন read staleness tolerate করতে পারে আর কোনটায় fresh data must, এটা ধরতে পারাটাও একটা skill।
উত্তর দেখুন আগে নিজে ভাবুন
সবাই যেভাবে ভাবে
“Replica আর backup এক জিনিস নয়। Backup হলো নির্দিষ্ট সময়ের snapshot, human mistake recover করার জন্য সেটা helpful। Replica সবসময় database এর সাথে sync থাকে।”
মূল idea ঠিক, কিন্তু একটা শব্দ বিপজ্জনক।
“সবসময় sync”: এই কথাটায় সার্প নজর দিন
Replica সবসময় sync নয়। Replica eventually sync হয়, instantly না; কারণ replication lag আছে। System design এ শব্দ precise হতে হবে।
Replication কেন backup এর substitute নয়?
Developer যদি ভুল করে primary তে DELETE FROM users চালায়, replication faithfully সেই delete সব replica তে copy
করবে। কয়েক second এর মধ্যেই সবগুলো replica থেকে data হারিয়ে যাবে। Replication ভুলটাকে carry করবে, prevent করবে
না।
Backup আলাদা জায়গায় stored, frozen in time, live operation এর উপর এর কোনো effect নেই। এই বৈশিষ্ট্যটাই backup কে escape gate বানায়।
উত্তর দেখুন আগে নিজে ভাবুন
সবাই যেভাবে ভাবে
“User cart এ add করা item দেখবে না। User আবার cart এ অ্যাড করবে, ফলে duplicate item অ্যাড হয়ে যেতে পারে। DB এর বদলে temporary cache use করি। পরে DB তে sync করব।“
কোথায় ঠিক
- User cart এ add করা item দেখতে পাবে না। ✓
- Duplicate item অ্যাড হয়ে যেতে পারে। ✓
কোথায় বিপজ্জনকভাবে ভুল
“DB এর বদলে cache”, এটা একটা dangerous thinking।
- Cache volatile: Redis restart হলে cart data হারিয়ে যায়।
- “পরে DB তে sync”: কথাটা vague। কখন save করবেন? Checkout আগে হলে? Sync fail করলে?
এটা multiple sources of truth তৈরি করে, যা system design এর সবচেয়ে বড় ভুল।
সঠিক solution: ৩টা option
- Read-after-Write Consistency (Sticky Reads): Write এর পর কিছু সময় ওই user এর reads primary তে route করুন।
- Cache-Aside Pattern: Cache থাকবে DB এর উপরে, replace হিসেবে নয়। DB থাকবে source of truth।
- Synchronous Replication: Critical write এর জন্য; replica confirm করার আগে user কে “done” বলবেন না।
প্রতি solution এর একটা cost আছে। Sticky reads এ primary তে বেশি load পড়ে। Cache এ বেশি complexity আসে। Sync replication এ write slow হয়। System design এ free fix বলে কিছু নেই।
১০ যে টার্মগুলো শিখলাম
| টার্ম | মানে |
|---|---|
| Replication | Multiple machine এ database এর copy। |
| Primary | যে database সব write handle করে। |
| Replica | Primary এর read-only copy, continuously sync হয়। |
| Failover | Primary down হলে একটা replica কে promote করে নতুন primary বানানো হয়। |
| Split Brain | একসাথে দুই primary active, এতে data corruption হয়। |
| Replication Lag | Primary write আর Replica তে sync হওয়ার মধ্যবর্তী delay। |
| Eventual Consistency | সব replica eventually match করবে, instantly না। |
| Strong Consistency | প্রতি read সর্বশেষ write দেখে, সবসময়। |
| Synchronous Replication | Replica confirm এর জন্য wait। Slower, safer। |
| Asynchronous Replication | Write immediately confirm, replication background এ চলে। Faster, কিন্তু failover এ data loss এর risk। |
| Backup | Point-in-time snapshot, human বা software mistake recover করে। |
| Cold Storage | Cheap, slow storage (S3 Glacier, tape)। |
| Read-after-Write / Sticky Reads | User write এর পর immediately ওই user এর reads primary থেকে। |
| Cache-Aside Pattern | Cache থাকে database এর উপরে; DB ই source of truth। |
| Source of Truth | Data এর authoritative version যেখানে থাকে। |
| Raft / Paxos / Zookeeper | কোন মেশিন primary হবে সেটা নিয়ে সবাইকে একমত করানোর algorithm বা tool। |
১১ সংক্ষিপ্ত সারাংশ
- Replication multiple machine এ database এর copy রাখে। এক primary write handle করে, replica reads handle করে, আর primary down হলে একটা replica কে promote করে primary বানানো হয়।
- Replication instant নয়; এই delay কে বলে Replication Lag। এটা Strong Consistency (slow, safe) আর Eventual Consistency (fast, stale) এর মধ্যে একটা trade-off তৈরি করে।
- Replication মেশিনের failure recover করতে help করে, আর Backup human mistake recover করতে help করে। দুটোই দরকার, দুটো এক জিনিস নয়।
১২ মনে রাখুন
- প্রতিটা solution একটা নতুন problem তৈরি করে। এখান থেকেই বোঝা যায়, System Design হলো trade-off এর বিষয়, perfect answer এর নয়।
- Source of Truth সবসময় clear রাখুন। Design এ multiple sources of truth থাকলে বুঝবেন design এ সমস্যা আছে।
- Replication আর Backup আলাদা threat এর জন্য। দুটো বিষয় গুলিয়ে ফেলবেন না।
- Database এর উপরে cache থাকবে, replacement হিসেবে নয়। DB থাকবে source of truth, cache হবে speed layer।
- Failover দেখতে সহজ। কঠিন হলো Detection, split brain, আর lost writes; এগুলো সবই real problem।
- Read pattern-ও write pattern এর মতোই important। কোন read এ fresh data দরকার আর কোনটায় stale হলেও চলবে, এটা বোঝাই হলো আসল design skill।