Database কে SPOF থেকে মুক্ত করা

সতর্কতা

এই সেশনেই প্রথমবার দেখবেন, প্রতিটা solution একটা নতুন সমস্যা তৈরি করে। একাধিক machine মিলে চলা system কে বলে distributed system। আর distributed system এ এটাই স্বাভাবিক নিয়ম।

০০ যে প্রশ্নগুলোর উত্তর খুঁজবো

এই প্রশ্নগুলোর উত্তর জানার পর আপনি replication বুঝবেন। Replication এর cost কী, সেটাও বুঝবেন। আর শিখবেন source of truth এর মতো একটা জরুরি 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 করছি?

সেশন ০২ এ আমরা web server বাড়িয়েছি। কিন্তু database এখনো একটাই, তাই সেটা এখনো SPOF (single point of failure)। Database down হলে পুরো system down হয়। এর চেয়েও খারাপ ঘটনা আছে। Disk নষ্ট হলে data চিরতরে হারিয়ে যায়।

আমরা আসলে দুটো জিনিস চাইছি:

Durability: Machine crash করলেও data হারায় না।
Availability: Machine down হলেও service চালু থাকে, user উত্তর পেতে থাকে।

শুনতে এক রকম লাগলেও এই দুটো আলাদা জিনিস।

Daily backup durability দেয়, কারণ গতকালের data ফিরিয়ে আনা যায়। কিন্তু availability দেয় না, কারণ restore চলার সময় service বন্ধ থাকে।
Live replica availability দেয়, কারণ সাথে সাথে অন্য machine দায়িত্ব নিতে পারে। কিন্তু দুটো machine একসাথে নষ্ট হলে সব data হারিয়ে যায়।

তাই দুটোই দরকার। একেকটা একেক সমস্যার সমাধান দেয়।

০২ একাধিক copy রাখার basic idea?

লাইব্রেরির গল্প

ধরুন একটা লাইব্রেরিতে প্রতিটা বইয়ের মাত্র একটা করে কপি আছে।

একজন বই issue করলে অন্য কেউ আর সেটা পড়তে পারেন না।
লাইব্রেরিতে আগুন লাগলে সব বই শেষ।
পরীক্ষার সময় ১০০ জন একই কপির জন্য ভিড় করেন।

এই সমস্যা মেটাতে লাইব্রেরি দুটো কাজ করতে পারে:

বইয়ের ফটোকপি বানানো (Replica): পাঠক বেশি হলে কপিও বেশি রাখা হয়। সবাইকে আর মূল কপির জন্য অপেক্ষা করতে হয় না।
আলাদা building এ একটা সংরক্ষিত কপি রাখা (Backup): এক building এ আগুন লাগলেও অন্য building এ বইটা নিরাপদ থাকে।

Database এর জন্যও আমরা ঠিক এই দুটো কাজ করবো।

Database Replication: Primary-Replica মডেল

Replication কী?

একাধিক machine এ database এর একাধিক copy রাখাকে বলে replication। একটা machine down হলেও অন্যগুলোতে data থেকে যায়।

যে database সব write নেয়, তাকে বলে Primary। যেগুলো Primary থেকে data copy করে রাখে, সেগুলো Replica। এই মডেলের পুরোনো নাম ছিলো Master-Slave। এখন সবাই Primary-Replica নামটাই ব্যবহার করে।

Primary সব write নেয়। Replica অনবরত Primary থেকে data copy করে। Replica থেকে শুধু read করা যায় (read-only)।

০৩ Read আর write আলাদা করবো কেন?

বেশিরভাগ application এ write এর চেয়ে read অনেক বেশি হয়:

Tweet: একবার লেখা হয়, হাজার জন পড়েন।
Order: একবার place হয়, কিন্তু অনেক পক্ষ সেটা পড়ে (user, warehouse, shipping)।
Post: একবার তৈরি হয়, শত শত মানুষ দেখেন।

সাধারণত প্রতি ১০০টা request এর মধ্যে ৮০টা থেকে ৯৫টা হয় read। তাই একটা Primary আর অনেকগুলো Replica মিলে বিপুল read traffic সামলাতে পারে।

সলিড অ্যারো দেখায় write, যেটা Primary তে যায়। হাইলাইট করা অ্যারো দেখায় read, যেটা Replica থেকে আসে। ডটেড লাইন দেখায় replication।

এতে যা পাই:

Read scale করে: Replica অ্যাড করলেই read এর ক্ষমতা বাড়ে।
Replica down হলেও চলে: এক replica down হলে অন্য replica থেকে read করা যায়।
Primary down হলেও চলে: Primary down হলে একটা replica কে নতুন primary বানানো হয়। একে বলে Failover।
ভারী query আলাদা থাকে: Analytics আর report এর মতো ভারী query replica তে চালান। Primary শুধু জরুরি কাজের জন্য খালি থাকে।
Latency কমে: User এর কাছাকাছি জায়গায় replica রাখা যায়। User তখন কাছের replica থেকে data পান, তাই উত্তর দ্রুত আসে।

০৪ Replica যদি read serve করতে পারে, সব কিছু কেন replica থেকে না?

কারণ এখানে একটা সমস্যা লুকিয়ে আছে। তার নাম Replication Lag।

Replication Lag কী?

Primary থেকে Replica তে data copy হতে কিছু সময় লাগে। এই দেরিকেই বলে Replication Lag।

সাধারণত এই দেরি কয়েক millisecond হয়। কখনো কখনো কয়েক second লাগে। Network খারাপ থাকলে কয়েক minute ও লাগতে পারে।

উদাহরণ:

Step 1: আপনি Facebook এর প্রোফাইল ছবি বদলালেন।
Update গেলো Primary DB তে। Primary তে এখন নতুন ছবি।

Step 2: Primary নতুন ছবিটা replica তে copy করা শুরু করলো।

Step 3: Copy শেষ হওয়ার আগেই আপনি page refresh করলেন।
Read গেলো Replica তে, যেখানে এখনো পুরোনো ছবি।

Step 4: পুরোনো ছবি দেখে ভাবলেন update fail করেছে।
আবার "update" click করলেন। একই update দুইবার হলো।

Eventual Consistency বনাম Strong Consistency

Eventual Consistency

Primary তে write হওয়ার পর replica গুলোতে সেটা পৌঁছাতে একটু সময় লাগে। এই সময়ে কোনো replica পুরোনো data দেখাতে পারে, আর দুটো replica দুই রকম উত্তর দিতে পারে। কিন্তু নতুন write না এলে কিছুক্ষণ পর সব replica একই data তে পৌঁছে যায়। “Eventually” মানে “শেষ পর্যন্ত”। অর্থাৎ সব copy শেষ পর্যন্ত মিলে যাবে, কিন্তু সাথে সাথে নয়। এই নিয়মকে বলে eventual consistency।

Strong Consistency

প্রতিটা read সবশেষ write এর data দেখে, যে copy থেকেই read করা হোক না কেন। এটা পাওয়ার একটা উপায় হলো Synchronous Replication: সব replica write confirm করার পরেই user কে “done” বলা হয়। তাই write ধীর হয়, কিন্তু কোনো read পুরোনো data পায় না।

Eventual Consistency	Strong Consistency
Fast	Slower
Scale করা সহজ	Scale করা কঠিন
Stale (পুরোনো) read হতে পারে	সবসময় fresh
Like, view count, comment এর জন্য উপযোগী	Bank, inventory, payment এর জন্য বাধ্যতামূলক

এই বিষয়টা পরে আরো গভীরে দেখবো। এখনকার জন্য মনে রাখুন: replication free নয়, এর একটা cost আছে।

০৫ Primary তো এখনো down হয়ে যেতে পারে, তখন কী হবে?

Primary down হলে সব write বন্ধ হয়ে যায়। এর সমাধান হলো Failover। Failover মানে একটা replica কে promote করে নতুন primary বানানো।

Primary down হওয়ার পর Replica 1 কে নতুন Primary বানানো হলো। Replica 2 এখন নতুন Primary থেকে data copy করে।

Failover কঠিন কেন?

Primary আসলেই down কিনা, বুঝবেন কীভাবে? হয়তো Primary শুধু ধীরে চলছে। হয়তো মাঝের network এর সংযোগ কেটে গেছে। Primary চালু থাকা অবস্থায় replica কে promote করলে দুটো primary একসাথে write নিতে থাকে। এই অবস্থাকে বলে Split Brain। তখন দুই জায়গায় দুই রকম data তৈরি হয়, আর কোনটা ঠিক সেটা বলার উপায় থাকে না।
কিছু write হারিয়ে যায় (Lost writes): Primary কিছু write নিয়েছিলো, কিন্তু সেগুলো replica তে copy হওয়ার আগেই down হয়ে গেছে। এই replica কে primary বানালে ওই write গুলো হারিয়ে যায়।
Failover এ সময় লাগে: কয়েক second থেকে কয়েক minute পর্যন্ত লাগে। এই সময়ে application কোনো write নিতে পারে না।

আধুনিক system এ Raft, Paxos, ZooKeeper এর মতো tool এই সমস্যা সামলায়। এরা কয়েকটা machine কে একমত করায় যে Primary আসলেই down কিনা, আর নতুন Primary কে হবে। নামগুলো এখন শুধু চিনে রাখুন, বিস্তারিত পরে দেখবো।

০৬ ৫টা Replica থাকলেও কি Backup দরকার?

হ্যাঁ। এই জায়গায় অনেক engineer ও ভুল করেন।

Replication আর Backup এক জিনিস নয়

Replication আপনাকে machine নষ্ট হওয়া থেকে বাঁচায়। কিন্তু ভুল করে একটা DELETE চালালে বা data corrupt হলে replication সেই ভুলটাও সাথে সাথে সব replica তে copy করে দেয়। Backup হলো একটা আলাদা copy, যেটা একটা নির্দিষ্ট সময়ে নেওয়া হয়েছে আর তারপর আর বদলায় না। তাই ভুল ঘটার পরেও backup থেকে আগের ঠিক data ফিরিয়ে আনা যায়।

Replication	Backup
Real-time copy	একটা নির্দিষ্ট সময়ের snapshot
Machine failure থেকে রক্ষা করে	Human mistake, corruption, malware থেকে রক্ষা করে
চালু থাকা machine এ থাকে	সস্তা, ধীর cold storage এ থাকে (S3, tape)
Recovery দ্রুত (কয়েক second বা minute)	Recovery ধীর (কয়েক ঘণ্টা পর্যন্ত)

একটা ভয়ের গল্প

একজন developer ভুল করে primary তে এই command টা চালিয়ে দিলেন:

DELETE FROM users;

এরপর কী হলো?

Primary DB সব user ডিলিট করে দিলো।
Replication এই DELETE সব replica তে পাঠিয়ে দিলো।
কয়েক second এর মধ্যে কোনো machine এই আর একজন user ও রইলো না।
Replication ভুলটাকে সব জায়গায় ছড়িয়ে দিলো।

এই অবস্থায় data ফিরে পাওয়ার একমাত্র উপায় হলো backup। গত রাতের snapshot থেকে data restore করতে হবে।

মনে রাখুন

Replication রক্ষা করে hardware failure থেকে। Backup রক্ষা করে software এর ভুল, মানুষের ভুল আর corruption থেকে। দুটোই দরকার।

০৭ User write করার পরের মুহূর্তেই read করলো, কী হবে?

User cart এ একটা item অ্যাড করলেন। এই write গেলো Primary তে। তারপর তিনি page refresh করলেন। এই read গেলো একটা Replica তে, যেখানে তখনো lag চলছে।

সমস্যা:

User নিজের অ্যাড করা item cart এ দেখতে পান না।
সমস্যাটা গুরুতর। User হয়তো আবার অ্যাড করবেন, ফলে item duplicate হবে। অথবা বিরক্ত হয়ে site ছেড়ে চলে যাবেন।

সবাই যেভাবে ভাবে

অনেকে বলেন, “DB এর বদলে cache ব্যবহার করি।” এটা একটা বিপজ্জনক চিন্তা।

Cache হলো RAM এ রাখা data এর একটা দ্রুত copy। এর বিস্তারিত সেশন ০৪ এ দেখবো। এখানে শুধু এটুকু জানলেই চলবে:

Cache volatile। অর্থাৎ cache server restart হলে RAM এর সব data, আর তার সাথে cart ও, হারিয়ে যায়।
“আগে cache এ অ্যাড করি, পরে DB তে sync করবো।” কিন্তু কখন? তার আগেই user checkout করে ফেললে? Sync fail করলে?

এতে একাধিক source of truth তৈরি হয়। System design এ এটা সবচেয়ে বড় ভুলগুলোর একটা।

সমাধান: ৩টা option

সমাধান ১: Read-After-Write Consistency (Sticky Reads)

যে user এইমাত্র write করেছেন, তার পরের read গুলো কিছু সময়ের জন্য Primary তে পাঠান (যেমন ৩০ second)। বাকি user রা আগের মতোই replica থেকে read করবেন।

User A cart এ item অ্যাড করলেন → Primary তে write।
পরের ৩০ second User A এর সব read → Primary থেকে।
৩০ second পর replica গুলো আপডেট হয়ে গেছে → আবার Replica থেকে read।

এটাই সবচেয়ে বেশি ব্যবহার হওয়া সমাধান।

সমাধান ২: Cache-Aside Pattern

Cache রাখুন DB এর উপরে, DB এর বদলে নয়। Cache-Aside এর পুরো নিয়ম সেশন ০৪ এ দেখবো।

Cart এ item অ্যাড:
১. Primary DB তে write করুন (source of truth)
২. Cache থেকে পুরোনো cart মুছে দিন

Cart read:
১. আগে cache দেখুন
২. Cache এ না পেলে (miss) Primary থেকে পড়ুন
৩. পড়া data cache এ রেখে দিন

Cache শুধু গতি বাড়ায়। Source of truth সবসময় DB।

সমাধান ৩: Synchronous Replication

User কে “done” বলার আগে replica গুলো write confirm করা পর্যন্ত অপেক্ষা করুন।

সব replica এর জন্য অপেক্ষা করলে: যেকোনো replica থেকে read করলেই fresh data পাওয়া যায়, তাই cart সমস্যা মিটে যায়। কিন্তু write ধীর হয়। আর একটা replica ধীর বা down হলে সব write আটকে যায়।
শুধু একটা replica এর জন্য অপেক্ষা করলে: একে বলে semi-synchronous replication। Primary write এর পরপরই down হলেও data হারায় না, কারণ অন্তত একটা replica তে সেটা আছে। কিন্তু বাকি replica গুলোতে lag থেকে যায়। তাই সেগুলো থেকে read করলে পুরোনো data আসতে পারে, cart সমস্যা পুরো মেটে না।
বেশিরভাগ database এর default setup হলো Asynchronous Replication। এতে Primary write করেই user কে জানিয়ে দেয়, আর replication background এ চলতে থাকে।

Source of Truth: একটা জরুরি concept

Source of Truth

Data এর আসল, নির্ভরযোগ্য version যেখানে থাকে, সেটাই Source of Truth। বাকি সব কিছু (cache, replica, search index) শুধু তার copy।

System design করার সময় সবসময় নিজেকে একটা প্রশ্ন করুন: এখানে আমার source of truth কোনটা?

Cart এর ক্ষেত্রে source of truth হলো Database। Cache হলো গতির জন্য রাখা copy। Replica হলো read এর জন্য রাখা copy।

“Source of truth কোনটা?” এই প্রশ্নের উত্তর এক বাক্যে দিতে না পারলে বুঝবেন, design এ সমস্যা আছে।

০৮ System এখন কেমন? এখনো কোনো single point of failure আছে?

সলিড অ্যারো দেখায় write, যেটা Primary তে যায়। হাইলাইট করা অ্যারো দেখায় read, যেটা Replica থেকে আসে। ডটেড লাইন দেখায় replication আর রাতের backup।

এখন পর্যন্ত কী কী ঠিক করা হলো?

Database availability: Replica গুলো read সামলায়। Primary down হলে failover হয়।
Data durability: নিয়মিত backup থাকায় data হারানোর ভয় কমেছে।
Read scaling: আরো replica অ্যাড করলে বিপুল read traffic replica গুলোই সামলে নেয়।

নতুন যেসব সমস্যা (Trade-offs)

Replication Lag: Replica সাথে সাথে আপডেট হয় না (eventual consistency), তাই পুরোনো data পড়ার সম্ভাবনা থাকে।
Failover Complexity: Split brain আর lost writes এর ঝুঁকি আছে। Primary আসলেই down কিনা, সেটা বোঝাও কঠিন।
Cost: Machine বেশি লাগে, monitoring ও বেশি লাগে।

যা এখনো বাকি

দূরের user এখনো বেশি latency পাবেন। Database যত দ্রুতই হোক, দূরের user এর কাছে data পৌঁছাতে সময় লাগবে।
সব write এখনো এক machine এ যায়। Write traffic বাড়লে এটা bottleneck হবে।
প্রতিটা request database থেকে ডেটা আনছে। মাঝে কোনো cache layer নেই।

০৯ মগজে প্রেশার দিন

আগে নিজে ভাবুন। তারপর দেখুন সবাই যেভাবে ভাবে, কেন সেটা ভুল, আর সঠিক চিন্তা কী।

প্রশ্ন ১: Replica থেকে stale data পাওয়ার সম্ভাবনা থাকে, তাহলে replica ব্যবহার করি কেন?

উত্তর দেখুন আগে নিজে ভাবুন

সবাই যেভাবে ভাবে

“Main goal হলো read আর write এর load ভাগ করা। একাধিক read node নিজের resource দিয়ে load সামলায়।”

এই চিন্তা ঠিক দিকে যাচ্ছে, কিন্তু সব কারণ বলছে না।

সঠিক উত্তর: ৫টা কারণ

Read আর write এর load আলাদা হয়: Primary শুধু write সামলায়।
Read horizontally scale করে: Replica অ্যাড করলেই আরো বেশি read সামলানো যায়।
Geographic distribution: Replica একাধিক বলে user রা যেখানে থাকেন, তার কাছাকাছি replica server বসানো যায়। User তখন কাছের replica থেকে data পান, তাই latency কমে।
ভারী query আলাদা থাকে: Analytics আর report এর মতো ভারী কিন্তু জরুরি নয় এমন query replica তে পাঠান। Primary কে শুধু সময়-সংবেদনশীল request এর জন্য রাখুন। Industry তে এটা প্রচলিত নিয়ম, কিন্তু অনেকে এই কারণটা বলতে ভুলে যান।
Failover candidate: Primary down হলে একটা replica নতুন primary হতে পারে।

Stale data এর cost নিয়েও ভাবুন। বাস্তবে বেশিরভাগ read এ সামান্য পুরোনো data চলে যায়। কিন্তু কোন read পুরোনো data সহ্য করতে পারে, আর কোন read এ fresh data লাগবেই, সেটা আলাদা করতে পারাটাও একটা skill।

প্রশ্ন ২: এক company বললো "আমাদের ৩টা replica আছে, তাই backup দরকার নেই।" তারা ভুল কেন?

উত্তর দেখুন আগে নিজে ভাবুন

সবাই যেভাবে ভাবে

“Replica আর backup এক জিনিস নয়। Backup হলো নির্দিষ্ট সময়ের snapshot, মানুষের ভুল ঠিক করতে সেটা কাজে লাগে। Replica সবসময় database এর সাথে sync থাকে।”

মূল idea ঠিক, কিন্তু একটা কথা বিপজ্জনক।

“সবসময় sync”: এই কথাটা খেয়াল করে দেখুন

Replica সবসময় sync থাকে না। Replication lag আছে বলে replica সাথে সাথে sync হয় না, একটু পরে হয়। System design এ প্রতিটা শব্দ সঠিক হতে হয়।

Replication কেন backup এর বিকল্প নয়?

Developer ভুল করে primary তে DELETE FROM users চালালে replication সেই delete হুবহু সব replica তে copy করবে। কয়েক second এর মধ্যে সব replica থেকে data হারিয়ে যাবে। Replication ভুলটাকে আটকায় না, বরং সব জায়গায় পৌঁছে দেয়।

Backup আলাদা জায়গায় রাখা থাকে। নেওয়ার পর সেটা আর বদলায় না, আর চালু database এ যা-ই ঘটুক, backup এ তার কোনো প্রভাব পড়ে না। এই কারণেই এমন ভুলের পর data ফিরে পাওয়ার একমাত্র উপায় হলো backup।

প্রশ্ন ৩: User cart এ item অ্যাড করলেন (Primary তে write), তারপর refresh করলেন (lag আছে এমন Replica থেকে read)। কী হবে? Solution কী?

উত্তর দেখুন আগে নিজে ভাবুন

সবাই যেভাবে ভাবে

“User cart এ অ্যাড করা item দেখবেন না। তিনি আবার অ্যাড করবেন, ফলে item duplicate হয়ে যেতে পারে। DB এর বদলে temporary cache ব্যবহার করি। পরে DB তে sync করবো।”

কোথায় ঠিক

User cart এ অ্যাড করা item দেখতে পাবেন না। ✓
Item duplicate হয়ে যেতে পারে। ✓

কোথায় বিপজ্জনকভাবে ভুল

“DB এর বদলে cache” ব্যবহার করা একটা বিপজ্জনক চিন্তা। (Cache হলো RAM এ রাখা data এর দ্রুত copy, বিস্তারিত সেশন ০৪ এ।)

Cache volatile। Cache server restart হলে cart এর data হারিয়ে যায়।
“পরে DB তে sync” কথাটা অস্পষ্ট। কখন save করবেন? তার আগেই checkout হয়ে গেলে? Sync fail করলে?

এতে একাধিক source of truth তৈরি হয়। System design এ এটা সবচেয়ে বড় ভুলগুলোর একটা।

সঠিক solution: ৩টা option

Read-after-Write Consistency (Sticky Reads): Write এর পর কিছু সময় ওই user এর read গুলো primary তে পাঠান।
Cache-Aside Pattern: Cache থাকবে DB এর উপরে, DB এর বদলে নয়। DB ই থাকবে source of truth।
Synchronous Replication: সব replica write confirm না করা পর্যন্ত user কে “done” বলবেন না। এটা শুধু critical write এর জন্য ব্যবহার করুন, কারণ এতে write ধীর হয়।

শিক্ষা

প্রতিটা solution এর একটা cost আছে। Sticky reads এ primary তে load বাড়ে। Cache আনলে complexity বাড়ে। Sync replication এ write ধীর হয়। System design এ বিনা খরচের কোনো সমাধান নেই।

১০ যে টার্মগুলো শিখলাম

টার্ম	মানে
Replication	একাধিক machine এ database এর copy রাখা।
Primary	যে database সব write নেয়।
Replica	Primary এর read-only copy, যেটা Primary থেকে অনবরত data copy করে।
Failover	Primary down হলে একটা replica কে promote করে নতুন primary বানানো।
Split Brain	একসাথে দুটো primary চালু থাকা, যাতে দুই জায়গায় দুই রকম data তৈরি হয়।
Replication Lag	Primary তে write আর Replica তে সেটা পৌঁছানোর মাঝের দেরি।
Eventual Consistency	সব replica শেষ পর্যন্ত একই data তে পৌঁছাবে, কিন্তু সাথে সাথে নয়।
Strong Consistency	প্রতিটা read সবসময় সবশেষ write দেখে।
Synchronous Replication	User কে “done” বলার আগে replica এর confirm এর জন্য অপেক্ষা করা। ধীর, কিন্তু নিরাপদ।
Semi-synchronous Replication	অন্তত একটা replica confirm করলেই “done” বলা। Data হারায় না, কিন্তু বাকি replica তে lag থাকে।
Asynchronous Replication	Write সাথে সাথে confirm হয়, replication background এ চলে। দ্রুত, কিন্তু failover এ data হারানোর ঝুঁকি আছে।
Backup	একটা নির্দিষ্ট সময়ের snapshot, যেটা মানুষের বা software এর ভুলের পর data ফিরিয়ে আনে।
Cold Storage	সস্তা কিন্তু ধীর storage (S3 Glacier, tape)।
Read-after-Write / Sticky Reads	Write এর পর কিছু সময় ওই user এর read গুলো primary থেকে করা।
Cache-Aside Pattern	Cache থাকে database এর উপরে; DB ই source of truth।
Source of Truth	Data এর নির্ভরযোগ্য, আসল version যেখানে থাকে।
Raft / Paxos / ZooKeeper	কোন machine primary হবে, সেটা নিয়ে সব machine কে একমত করানোর algorithm বা tool।

১১ শর্ট সামারি

Replication একাধিক machine এ database এর copy রাখে। একটা primary write নেয়, replica গুলো read সামলায়। Primary down হলে একটা replica কে promote করে primary বানানো হয়।
Replication সাথে সাথে হয় না, এই দেরিকে বলে Replication Lag। এর ফলে একটা trade-off তৈরি হয়: Strong Consistency (ধীর, কিন্তু সবসময় fresh) অথবা Eventual Consistency (দ্রুত, কিন্তু মাঝে মাঝে পুরোনো data)।
Replication machine নষ্ট হওয়া থেকে বাঁচায়, আর Backup বাঁচায় মানুষের ভুল থেকে। দুটোই দরকার, আর দুটো এক জিনিস নয়।

১২ মনে রাখুন

প্রতিটা solution একটা নতুন problem তৈরি করে: তাই System Design হলো trade-off বেছে নেওয়ার বিষয়, perfect answer খোঁজার নয়।
Source of Truth সবসময় পরিষ্কার রাখুন: Design এ একাধিক source of truth থাকলে বুঝবেন, design এ সমস্যা আছে।
Replication আর Backup আলাদা বিপদের জন্য: দুটোকে গুলিয়ে ফেলবেন না।
Cache থাকবে database এর উপরে, বদলে নয়: DB থাকবে source of truth, cache শুধু গতি বাড়াবে।
Failover দেখতে সহজ: কঠিন অংশ হলো Primary আসলেই down কিনা বোঝা, split brain আর lost writes। এগুলো সবই বাস্তব সমস্যা।
Read pattern ও write pattern এর মতোই জরুরি: কোন read এ fresh data লাগবে আর কোনটায় পুরোনো হলেও চলবে, এটা বোঝাই আসল design skill।