CAP Theorem
- ●CAP theorem বলে: network partition হলে একটা distributed system একসাথে Consistency আর Availability — দুটোই দিতে পারে না, যেকোনো একটা বেছে নিতে হয়।
- ●CP সিস্টেম (যেমন HBase, MongoDB) consistency বেছে নেয়, AP সিস্টেম (যেমন Cassandra, DynamoDB) availability বেছে নেয়।
- ●PACELC theorem CAP-কে বাড়িয়ে বলে — partition না থাকলেও latency আর consistency-র মধ্যে trade-off থাকে।
সমস্যাটা কী?
ধরো তোমার ব্যাংকিং অ্যাপের ডেটা দুটো data center-এ রাখা — একটা ঢাকায়, একটা সিঙ্গাপুরে। দুটো সবসময় একে অপরের সাথে sync থাকে। এখন হঠাৎ দুটোর মাঝখানের network cable কেটে গেল (এটাকে বলে partition)। ঢাকার server জানে না সিঙ্গাপুরে কী হচ্ছে, আর উল্টোটাও।
এই মুহূর্তে এক গ্রাহক ঢাকায় বসে টাকা তুলতে চাইছেন। তোমার সামনে দুটো পথ:
১. "দুঃখিত, এখন কাজ করছে না" — কারণ তুমি নিশ্চিত নও সিঙ্গাপুরের balance কত। (সঠিকতা রক্ষা করলে, কিন্তু সেবা বন্ধ) ২. "নাও, টাকা দিচ্ছি" — সিঙ্গাপুরের সাথে না মিলিয়েই। (সেবা চালু, কিন্তু ভুল balance-এর ঝুঁকি)
এই দ্বিধাটাই CAP theorem-এর কেন্দ্রে। তুমি দুটোই একসাথে পাবে না।
মূল ধারণা
CAP theorem (Eric Brewer, ২০০০) বলে: কোনো distributed data system একসাথে এই তিনটির মধ্যে সর্বোচ্চ দুটো নিশ্চিত করতে পারে — Consistency, Availability, এবং Partition tolerance।
তিনটি অংশ পরিষ্কার করে নিই:
- Consistency (C) — প্রতিটা read সবসময় সবচেয়ে সাম্প্রতিক লেখা (write) ডেটা ফেরত দেবে, নয়তো error দেবে। সব node একই ছবি দেখে।
- Availability (A) — প্রতিটা request একটা (non-error) উত্তর পাবে, যদিও সেটা সর্বশেষ ডেটা নাও হতে পারে। সিস্টেম কখনো "না" বলে না।
- Partition tolerance (P) — node-গুলোর মধ্যে যোগাযোগ বিচ্ছিন্ন (partition) হলেও সিস্টেম কাজ করে যাবে।
কীভাবে কাজ করে
কেন partition-এ মাত্র দুটো?
আসল কথা হলো — distributed system-এ partition tolerance ঐচ্ছিক নয়। যেকোনো বাস্তব network কখনো না কখনো fail করবেই (cable কাটা, server crash, সাময়িক slowness)। তাই P তোমাকে রাখতেই হবে।
সুতরাং প্রশ্নটা আসলে: partition হলে তুমি C রাখবে নাকি A? এই কারণেই বাস্তবে পছন্দটা দাঁড়ায় CP বনাম AP।
| পরিস্থিতি | Consistency বেছে নিলে (CP) | Availability বেছে নিলে (AP) |
|---|---|---|
| Partition হলো | নিশ্চিত না হওয়া পর্যন্ত request আটকে রাখে / error দেয় | পুরোনো ডেটা দিয়েও response দিতে থাকে |
| User-এর অভিজ্ঞতা | "এখন কাজ করছে না" | "কাজ করছে, কিন্তু একটু পুরোনো তথ্য" |
| উপযুক্ত | ব্যাংক, payment, inventory | সোশ্যাল ফিড, like count, cart |
Partition না থাকলে?
যখন network ঠিকঠাক, তখন একটা ভালো সিস্টেম C আর A দুটোই দিতে পারে। CAP-এর trade-off শুধু partition-এর মুহূর্তেই কামড় দেয়।
ভাবো একটা দোকানের দুটো শাখা — ধানমন্ডি আর গুলশান — একটা শেয়ার্ড স্টক খাতা রাখে ফোনে মিলিয়ে। হঠাৎ ফোন লাইন কেটে গেল (partition)। এখন গুলশানে এক গ্রাহক শেষ পিস টিভিটা কিনতে চাইছেন। Consistency পথ: "ধানমন্ডির সাথে মিলিয়ে না নিলে বিক্রি করব না" — হয়তো ওটা ওখানে আগেই বিক্রি হয়ে গেছে। Availability পথ: "বিক্রি করে দিই" — পরে দেখা গেল দুই শাখাই একই টিভি বিক্রি করেছে (oversold)। দুটোই একসাথে নিরাপদে পাওয়া যাচ্ছে না — লাইন কাটা থাকা অবস্থায়।
প্রকারভেদ
CP সিস্টেম (Consistency + Partition tolerance)
Partition-এ consistency রক্ষা করতে গিয়ে availability ছাড়ে। যেখানে ভুল ডেটা দেওয়া বিপদজনক, সেখানে এরা মানানসই।
- HBase — strong consistency দেয়; region unavailable হলে সেই অংশ read/write বন্ধ থাকে।
- MongoDB (default config-এ) — একটা primary node-এ write হয়; primary হারিয়ে গেলে নতুন election না হওয়া পর্যন্ত write আটকে যায়।
AP সিস্টেম (Availability + Partition tolerance)
Partition-এও সবসময় response দেয়, পরে ডেটা মিলিয়ে নেয় (eventual consistency)।
- Cassandra — কোনো node সাড়া না দিলেও অন্য replica থেকে উত্তর দেয়; tunable consistency দিয়ে দরকারে শক্ত করা যায়।
- DynamoDB — Amazon-এর design, যা availability-কে সর্বোচ্চ গুরুত্ব দেয়; default-এ eventually consistent read দেয়।
PACELC — CAP-এর পরের গল্প
CAP শুধু partition-এর কথা বলে, কিন্তু partition তো বিরল। PACELC theorem বলে:
Partition হলে A বা C বেছে নাও; Else (স্বাভাবিক সময়েও) Latency বা Consistency-র মধ্যে একটা বেছে নিতে হয়।
মানে partition না থাকলেও, সব node-এ ডেটা মিলিয়ে নিতে গেলে latency বাড়ে। Cassandra তাই PA/EL (availability + low latency), আর একটা strongly-consistent SQL সিস্টেম PC/EC ধাঁচের।
কখন ব্যবহার করবে / করবে না
টাকা, stock, seat booking — যেখানে "একটু পুরোনো ডেটা" মানেই বিপদ — সেখানে CP বেছে নাও। Like, view count, timeline, shopping cart — যেখানে সাময়িক অমিল চলে — সেখানে AP বেছে নিলে সিস্টেম সবসময় চালু থাকবে।
সবচেয়ে বড় ভুল বোঝাবুঝি: লোকে ভাবে "আমি C, A, P-এর যেকোনো ২টো যখন খুশি বাছতে পারি"। বাস্তবে P ছাড়া distributed system হয়ই না — তাই আসল পছন্দ শুধু CP নাকি AP। আর মনে রেখো, এটা পুরো সিস্টেমের নয়, প্রায়ই প্রতিটা operation-ভিত্তিক সিদ্ধান্ত।
বাস্তব উদাহরণ
Amazon-এর shopping cart AP-র চমৎকার উদাহরণ। তারা চায় cart সবসময় কাজ করুক — partition-এর সময় তুমি একই product দুটো ডিভাইস থেকে যোগ করলে দুটো কপি দেখা যেতে পারে, কিন্তু পরে merge হয়ে যায়। তাদের যুক্তি: "একটু পুরোনো cart দেখানো" ক্ষতিকর নয়, কিন্তু "cart কাজ করছে না" সরাসরি বিক্রি হারায়। অন্যদিকে তাদের payment আর order finalize ধাপ অনেক বেশি consistency-নির্ভর।
"Is your system CP or AP?" — এই প্রশ্নের উত্তরে কখনো একটা শব্দে থেমে যেও না। বলো: "এটা use-case ভিত্তিক — checkout-এ আমি CP চাই, কিন্তু product browsing বা recommendation-এ AP যথেষ্ট।" এই nuance দেখালে তুমি theory মুখস্থ নয়, সত্যিই বুঝেছ তা প্রমাণ হয়। PACELC উল্লেখ করলে বোনাস পয়েন্ট।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. CAP theorem অনুযায়ী network partition-এর সময় তুমি কোন দুটোর মধ্যে একটা বেছে নিতে বাধ্য?
2. Cassandra সাধারণত কোন ধরনের সিস্টেম?
3. PACELC theorem CAP-এর সাথে নতুন কী যোগ করে?