CAP theorem: সহজ ভাষায়, উদাহরণসহ
CAP distributed system-এর সবচেয়ে উদ্ধৃত অথচ সবচেয়ে ভুল বোঝা ধারণা। এটি আসলে কী বলে এবং database বাছাইয়ে এর মানে কী।
CAP theorem সেই distributed system নিয়ে, যেখানে data একাধিক মেশিনে থাকে। এতে তিনটি বৈশিষ্ট্য আছে:
- Consistency (C): প্রতিটি read সর্বশেষ write দেখে, যেন কপি একটাই।
- Availability (A): সচল node-এ করা প্রতিটি request উত্তর পায়।
- Partition tolerance (P): node-দের মধ্যের নেটওয়ার্ক ভেঙে গেলেও সিস্টেম চলে।
আসল দাবিটা
নেটওয়ার্ক ফেল করবেই, তাই P ছাড়া যায় না। Theorem বলে: partition হলে C আর A-র মধ্যে একটি বেছে নিতে হবে। "সবসময় তিনটির মধ্যে যেকোনো দুটি" কথাটা ঠিক নয়। নেটওয়ার্ক ঠিক থাকলে দুটোই পাওয়া যায়।
একটি বাস্তব উদাহরণ
দুটি data centre-এ একটি অ্যাকাউন্টের balance-এর কপি আছে। দুটির মধ্যের লিংক কেটে গেল, আর এক জায়গায় user টাকা তুলল।
- Consistency বাছলে (CP): অন্য সাইট লিংক ফিরে না আসা পর্যন্ত উত্তর দিতে অস্বীকার করে। Data ঠিক থাকে, কিন্তু কিছু user error পায়।
- Availability বাছলে (AP): দুই সাইটই উত্তর দেয়, পরে sync করে। কেউ error পায় না, কিন্তু কিছুক্ষণ দুই সাইট আলাদা balance দেখাতে পারে।
কোন সিস্টেম কোনদিকে ঝোঁকে
- Consistency আগে: ZooKeeper, etcd-এর মতো coordination সিস্টেম এবং single leader-এর relational setup।
- Availability আগে: Cassandra, DynamoDB ডিফল্টভাবে এদিকে ঝোঁকে, আর অনেকগুলো tune করা যায়।
CAP-এর বাইরে
Partition না থাকলেও latency আর consistency-র মধ্যে লেনদেন থাকে। প্রতিটি replica-র নিশ্চিতকরণের অপেক্ষা নিরাপদ কিন্তু ধীর। এটিকে PACELC ধারণা বলে।
কীভাবে কাজে লাগাবেন
নিজেকে জিজ্ঞেস করুন: এই feature-এ ভুল উত্তর বেশি খারাপ, না উত্তর না পাওয়া? ব্যাংক ট্রান্সফারে সঠিকতা লাগে। "লাইক" কাউন্টার কয়েক সেকেন্ড পুরোনো হলে ক্ষতি নেই।
মূল কথা: CAP হলো failure পরিস্থিতির জন্য feature অনুযায়ী করা একটি সিদ্ধান্ত, কোনো database-এর গায়ে লাগানো লেবেল নয়।
System Design সিরিজের 3 নম্বর পর্ব (মোট ১৫)। আগের পর্ব: Latency বনাম throughput: সিস্টেম ডিজাইনের দুই সংখ্যা.
