Strong vs Eventual Consistency
- ●Strong consistency মানে লেখার পরপরই সবাই সবসময় সর্বশেষ (latest) value দেখে।
- ●Eventual consistency মানে কিছুক্ষণ পুরোনো data দেখা যেতে পারে, তবে অল্প সময়ে সব copy মিলে যায় (converge)।
- ●Strong = বেশি সঠিক কিন্তু ধীর ও কম available; Eventual = দ্রুত ও বেশি available কিন্তু সাময়িকভাবে পুরোনো data।
সমস্যাটা কী?
ধরো তোমার app-এর data একটাই server-এ না রেখে কয়েকটা জায়গায় copy করে রাখা আছে — একটা ঢাকায়, একটা সিঙ্গাপুরে, একটা লন্ডনে। এই copy রাখাকে বলে Replication। সুবিধা: user যেখানে আছে, কাছের copy থেকে দ্রুত data পায়, আর একটা server মরলেও অন্যগুলো চলে।
কিন্তু সমস্যা: কেউ ঢাকার copy-তে কিছু লিখলে, সিঙ্গাপুর আর লন্ডনের copy তো সাথে সাথে জানে না। সেই খবর পৌঁছাতে কয়েক মিলিসেকেন্ড থেকে কয়েক সেকেন্ড লাগে।
এখন প্রশ্ন: লেখার পরপরই অন্য জায়গা থেকে কেউ read করলে সে কি সর্বশেষ value পাবে, নাকি পুরোনো value?
- যদি জোর করো "সবাই সবসময় latest দেখবে" — সেটা Strong Consistency।
- যদি বলো "একটু দেরিতে হলেও সব copy শেষমেশ মিলে যাবে" — সেটা Eventual Consistency।
প্রথমটা: Strong Consistency
Strong Consistency মানে — write সফল হওয়ার পরে যেকোনো জায়গা থেকে read করলে সবাই সর্বশেষ মানটাই পাবে। পুরোনো data দেখার কোনো সুযোগ নেই।
এটা নিশ্চিত করতে system-কে বাড়তি কাজ করতে হয়: লেখার সময় সব (বা বেশিরভাগ) copy-কে নিশ্চিত করতে হয় যে তারা update পেয়েছে, তবেই write "সফল" বলা হয়।
সুবিধা:
- সবসময় সঠিক। কোনো বিভ্রান্তি নেই, পুরোনো data নেই।
- টাকা, stock/inventory, seat booking-এর মতো জায়গায় অপরিহার্য।
অসুবিধা:
- ধীর (বেশি latency)। সব copy-র সাথে সমন্বয় করতে সময় লাগে।
- কম available। কোনো একটা জরুরি copy বা network লিঙ্ক বিচ্ছিন্ন হলে system লেখা/পড়া আটকে দিতে পারে — কারণ সে "নিশ্চিত না হয়ে" উত্তর দিতে রাজি না।
দ্বিতীয়টা: Eventual Consistency
Eventual Consistency মানে — write হওয়ার সাথে সাথে সব copy-তে পৌঁছায় না, তাই কিছুক্ষণ কেউ পুরোনো value দেখতে পারে। কিন্তু নতুন কোনো লেখা না হলে অল্প সময়েই সব copy এক হয়ে যায়। এই "সব copy মিলে যাওয়া"-কে বলে Convergence।
সুবিধা:
- দ্রুত। লেখার সময় সব copy-র জন্য অপেক্ষা করতে হয় না; কাছের copy-তে লিখে সাথে সাথে সফল বলে দেয়।
- বেশি available। একটা copy বা network লিঙ্ক বিচ্ছিন্ন হলেও বাকিরা কাজ চালিয়ে যায়; পরে মিলিয়ে নেয়।
অসুবিধা:
- সাময়িকভাবে পুরোনো (stale) data। "আমার comment দেখাচ্ছে না কেন?" — refresh দিলে এসে যায়।
- দুই জায়গায় একসাথে আলাদা লেখা হলে conflict হতে পারে, সেটা সামলানোর নিয়ম লাগে।
একটা মাঝামাঝি দরকারি ধারণা: Read-Your-Writes — তুমি নিজে যা লিখেছ অন্তত তুমি নিজে সাথে সাথে সেটা পড়তে পারবে (যদিও বাকিরা একটু পরে দেখবে)। অনেক eventual system এটুকু আলাদাভাবে নিশ্চিত করে, যাতে নিজের post নিজের কাছে "হারিয়ে গেল" মনে না হয়।
Strong consistency হলো অফিসের একটা মাত্র হোয়াইটবোর্ড — কেউ কিছু লিখলে যে-ই তাকাবে সে-ই হুবহু সর্বশেষ লেখাটা দেখবে, কোনো গরমিল নেই। কিন্তু লিখতে হলে সবার সামনে বোর্ডের কাছে যেতে হয় (ধীর)।
Eventual consistency হলো মুখে মুখে খবর ছড়ানো — তুমি একজনকে বললে, সে আরেকজনকে। ৫ মিনিট পর পুরো অফিস জানে (converge), কিন্তু ঠিক এই মুহূর্তে কেউ হয়তো এখনও জানে না (stale)। এটা দ্রুত আর কেউ ছুটিতে থাকলেও আটকায় না।
পাশাপাশি তুলনা
| বিষয় | Strong Consistency | Eventual Consistency |
|---|---|---|
| Read করলে কী পাও | সবসময় সর্বশেষ value | কিছুক্ষণ পুরোনো হতে পারে |
| Latency (দ্রুততা) | বেশি (ধীর) | কম (দ্রুত) |
| Availability | তুলনামূলক কম | বেশি |
| Network সমস্যায় আচরণ | আটকে দিতে পারে | চলতে থাকে |
| জটিলতা | লেখায় সমন্বয় বেশি | conflict সামলানো লাগে |
| উপযুক্ত data | টাকা, inventory, booking | like, view count, feed, profile |
মূল trade-off এক বাক্যে: সঠিকতা (correctness) বনাম দ্রুততা ও সচলতা (latency + availability)। দুটো একসাথে সর্বোচ্চ মাত্রায় পাওয়া যায় না।
কখন কোনটা বেছে নেবে
- টাকা বা যেখানে ভুল ক্ষতিকর — strong। Bank balance, payment, seat/ticket booking, inventory। এক টাকা দু'বার খরচ বা একই সিট দু'জনকে বিক্রি — অগ্রহণযোগ্য।
- যেখানে একটু পুরোনো data ক্ষতি করে না — eventual। Social media-র like/view count, news feed, comment, profile bio। ২ সেকেন্ড পরে like count ঠিক হলে কারও ক্ষতি নেই, কিন্তু দ্রুত ও সবসময় চালু থাকা জরুরি।
সবচেয়ে সাধারণ ভুল: সবকিছুতে strong consistency চাওয়া "কারণ ওটাই তো নিরাপদ।" এতে system অকারণে ধীর ও কম available হয়ে যায়। সঠিক প্রশ্ন হলো — "এই নির্দিষ্ট data কি কয়েক সেকেন্ড পুরোনো হলে আসলেই সমস্যা?" বেশিরভাগ data-র উত্তর "না।" তাই data ধরে ধরে আলাদা সিদ্ধান্ত নাও — balance-এ strong, like-এ eventual।
বাস্তব উদাহরণ
- Amazon DynamoDB ডিফল্টে eventual consistency দেয় (দ্রুত, সস্তা), কিন্তু চাইলে নির্দিষ্ট read-এ strong consistency বেছে নেওয়া যায় — মানে একই system-এ দুটোই।
- Banking ও payment system core ledger-এ strong consistency রাখে; ভুল balance অগ্রহণযোগ্য।
- Facebook/Instagram like ও view count-এ eventual consistency ব্যবহার করে — তাই মাঝে মাঝে count একটু ওঠানামা করে দেখো, পরে মিলে যায়।
- DNS বিশ্বজোড়া eventual — একটা domain-এর address বদলালে সব জায়গায় পৌঁছাতে কিছুটা সময় (propagation) লাগে।
Interview-তে এটা CAP theorem-এর সাথে যুক্ত করো: "Network partition হলে আমাকে consistency আর availability-র একটা বেছে নিতে হবে। Payment system হলে আমি consistency বাঁচাব (CP), social feed হলে availability (AP)।" — এভাবে বললে বোঝা যায় তুমি trade-off-টা data-ভিত্তিক করে ভাবছ, গায়ের জোরে না।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Eventual consistency-তে লেখার ঠিক পরের মুহূর্তে read করলে কী হতে পারে?
2. Bank account-এর balance-এর জন্য সাধারণত কোনটা দরকার?
3. Read-your-writes guarantee মানে কী?