Consistency Models
- ●Consistency model হলো একটা চুক্তি — read করলে কোন write দেখা যাবে, সেটা কতটা শক্ত নিশ্চয়তা দেয়।
- ●Linearizability সবচেয়ে শক্ত, eventual consistency সবচেয়ে দুর্বল; মাঝে causal, read-your-writes, monotonic reads ইত্যাদি।
- ●শক্ত consistency সুবিধাজনক কিন্তু ধীর ও কম available; তাই সঠিক model বেছে নেওয়া trade-off-এর খেলা।
সমস্যাটা কী?
ডেটা যখন একটামাত্র মেশিনে থাকে, জীবন সহজ — যা লিখলে তাই পড়বে। কিন্তু availability আর scale-এর জন্য আমরা ডেটা একাধিক জায়গায় replicate করি। এখন একটা replica-তে write হলো, কিন্তু সেটা অন্য replica-তে পৌঁছাতে কিছু সময় লাগে। এই ফাঁকে যদি কেউ পুরোনো replica থেকে read করে, সে stale (বাসি) ডেটা পাবে।
ধরো তুমি bKash-এ ৫০০ টাকা পাঠালে। পাঠানোর সাথে সাথে balance চেক করলে যদি দেখায় টাকা এখনো আছে — তুমি ঘাবড়ে যাবে। আবার একজন ব্যবহারকারী Facebook-এ পোস্ট দিলো, কমেন্ট এলো; কিন্তু কেউ যদি কমেন্ট দেখে অথচ মূল পোস্টটাই না দেখে — সেটা বিভ্রান্তিকর।
প্রশ্ন হলো: distributed storage থেকে read করলে ঠিক কী দেখার নিশ্চয়তা পাবে? এই নিশ্চয়তার আনুষ্ঠানিক সংজ্ঞাই হলো consistency model।
মূল ধারণা
Consistency model: একটি storage system আর তার ব্যবহারকারীর মধ্যে একটি চুক্তি, যা নির্ধারণ করে concurrent read এবং write অপারেশনের ফলাফল কী হতে পারে — অর্থাৎ কোন read কোন write-এর প্রভাব দেখতে বাধ্য।
মূল কথাটা হলো একটা spectrum বা বর্ণালী। একদিকে আছে strong consistency — খুব শক্ত নিশ্চয়তা, ব্যবহার করা সহজ, কিন্তু ধীর এবং network partition-এ unavailable হতে পারে (CAP theorem অনুযায়ী)। আরেকদিকে আছে weak/eventual consistency — দ্রুত, highly available, কিন্তু পুরোনো ডেটা দেখার ঝুঁকি থাকে।
কোনো model "ভালো" বা "খারাপ" নয়; প্রতিটার আলাদা trade-off। ব্যাংকের balance-এ শক্ত নিশ্চয়তা চাই, কিন্তু Instagram-এর like count-এ একটু দেরি হলেও কেউ মারা যাবে না।
কীভাবে কাজ করে
Strong থেকে weak — বর্ণালী
| Model | নিশ্চয়তা | গতি/Availability |
|---|---|---|
| Linearizability | একটিমাত্র সর্বশেষ value, real-time অনুযায়ী | সবচেয়ে কম |
| Sequential | সবাই এক ক্রমে দেখবে, তবে real-time বাধ্য নয় | মাঝারি |
| Causal | কারণ-ফল সম্পর্কের ক্রম রক্ষিত | ভালো |
| Read-your-writes | নিজের write নিজে দেখবে | ভালো |
| Monotonic reads | একবার নতুন দেখলে আর পেছাবে না | ভালো |
| Eventual | শেষমেশ সব replica মিলে যাবে | সর্বোচ্চ |
Linearizability
সবচেয়ে শক্ত। মনে হবে পুরো system-এ একটামাত্র copy আছে, আর প্রতিটা অপারেশন একটা নির্দিষ্ট মুহূর্তে atomically ঘটছে। একবার কোনো write complete হলে, তার পরের যেকোনো read অবশ্যই সেই নতুন value (বা আরও নতুন) দেখবে। bKash balance এর জন্য আদর্শ।
Sequential consistency
সব প্রসেস অপারেশনগুলোকে একই ক্রমে দেখবে, কিন্তু সেই ক্রম real-time-এর সাথে মিলতে হবে না। অর্থাৎ আমি আগে কিছু করলেও system সেটা পরে ঘটেছে বলে সাজাতে পারে — যতক্ষণ সবাই একই গল্প দেখে।
Causal consistency
যদি A ঘটনা B-এর কারণ হয় (যেমন পোস্ট তারপর কমেন্ট), তাহলে সবাই A-কে B-এর আগেই দেখবে। কিন্তু দুটো unrelated (concurrent) পোস্ট বিভিন্ন ইউজার ভিন্ন ক্রমে দেখতে পারে — তাতে অসুবিধা নেই।
Client-centric গ্যারান্টি
- Read-your-writes: নিজের লেখা নিজে পরে দেখতে পাবে।
- Monotonic reads: একবার নতুন version দেখার পর পরের read পুরোনোতে ফিরবে না।
প্রকারভেদ
ভাবো একটা চক্ষু হাসপাতালের সিরিয়াল বোর্ড। Linearizability মানে — বোর্ডে এই মুহূর্তে যে নম্বর দেখাচ্ছে, ঠিক সেটাই সবাই একসাথে দেখছে, কোনো দেরি নেই। Causal মানে — ডাক্তার "১৫ নম্বর আসুন" বলার পরই বোর্ডে ১৫ দেখানো হবে, উল্টোটা নয়; তবে দুটো আলাদা কাউন্টারের নম্বর কে আগে দেখলো তা ভিন্ন হতে পারে। Eventual মানে — বোর্ড একটু পুরোনো নম্বর দেখাচ্ছে, কিন্তু কিছুক্ষণ পর ঠিক হয়ে যাবে; তাড়া না থাকলে সমস্যা নেই।
কখন ব্যবহার করবে / করবে না
- Linearizability: ব্যাংকিং, inventory, distributed lock, leader election — যেখানে ভুল মানে টাকা/ডেটা ক্ষতি।
- Causal: social feed, comment thread, collaborative app — যেখানে কারণ-ফল ঠিক থাকলেই চলে।
- Eventual: like count, view count, DNS, shopping cart — যেখানে availability ও গতি বেশি জরুরি।
"Eventual consistency" মানে এই নয় যে ডেটা শেষমেশ "সঠিক" হবে। concurrent write হলে conflict resolution না থাকলে ডেটা হারাতে পারে। আবার strong consistency বেছে নিলে মনে রেখো — network partition-এর সময় system unavailable হয়ে যেতে পারে (CAP)। "শক্ত মানেই ভালো" এই ভুল ধারণা থেকে অনেকে অপ্রয়োজনে latency আর downtime ডেকে আনে।
বাস্তব উদাহরণ
- Google Spanner: TrueTime ব্যবহার করে external consistency (linearizability-র চেয়েও শক্ত) দেয়, যদিও কিছুটা latency-র বিনিময়ে।
- Amazon DynamoDB: ডিফল্ট eventually consistent read (সস্তা ও দ্রুত), চাইলে strongly consistent read (ব্যয়বহুল)।
- Apache Cassandra: tunable consistency — quorum দিয়ে strong, ONE দিয়ে দ্রুত কিন্তু দুর্বল।
- MongoDB: read/write concern দিয়ে তুমি model বেছে নিতে পারো — "majority" দিলে শক্ত, "local" দিলে দ্রুত।
- Facebook TAO: social graph-এ মূলত read-your-writes ও eventual consistency-র মিশ্রণ ব্যবহার করে scale সামলায়।
ইন্টারভিউতে consistency নিয়ে প্রশ্ন এলে কখনো একটা শব্দে উত্তর দিও না। আগে জিজ্ঞেস করো "এই ডেটার ভুল হলে কী ক্ষতি?" — টাকা হলে linearizability, feed হলে causal, counter হলে eventual। এই trade-off ভিত্তিক চিন্তাটাই senior engineer-এর লক্ষণ। আর CAP theorem-কে consistency-র সাথে গুলিয়ে ফেলো না — CAP partition-এর সময়ের আচরণ, consistency model সবসময়ের চুক্তি।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. সবচেয়ে শক্ত (strongest) single-object consistency model কোনটি?
2. Read-your-writes consistency কী নিশ্চিত করে?
3. Causal consistency-তে কী সংরক্ষিত থাকে?