CAP থিওরি কী?
🔹 CAP থিওরি কী?
CAP থিওরি (বা Brewer’s theorem) হলো এক ধরনের তত্ত্ব যেটা বলে, কোনো Distributed System (যেমন Distributed Database) একই সাথে নিচের তিনটি জিনিস পুরোপুরি দিতে পারবে না:
-
C – Consistency (সঙ্গতি/একই রকম ফলাফল)
👉 সিস্টেমের সব নোডে (server/database copy) ডেটা একদম একই থাকবে।
উদাহরণ: তুমি যদি একটি ডাটাবেজে নতুন ডেটা লেখো, অন্য নোড থেকেও তা সঙ্গে সঙ্গে দেখতে পাবে। -
A – Availability (উপলভ্যতা)
👉 সিস্টেম সবসময় অনলাইন থাকবে এবং ইউজারের রিকোয়েস্টের জবাব দেবে।
উদাহরণ: সার্ভারের কোনো সমস্যা হলেও ইউজার খালি হাতে ফিরবে না; কিছু না কিছু রেসপন্স পাবে। -
P – Partition Tolerance (বিভাজন সহনশীলতা)
👉 নেটওয়ার্কে সমস্যা হলেও (server একে অপরের সাথে যোগাযোগ করতে না পারলেও) সিস্টেম কাজ চালিয়ে যাবে।
উদাহরণ: সার্ভারের কিছু অংশ বিচ্ছিন্ন হলেও বাকি অংশ ইউজারকে সার্ভিস দিবে।
🔹 CAP থিওরির মূল বক্তব্য
তুমি একই সাথে তিনটা (C, A, P) একসাথে পাবেই না।
তুমি সর্বোচ্চ ২টা পেতে পারো।
মানে, কোনো Distributed Database ডিজাইন করার সময় তোমাকে বেছে নিতে হয় – কোন দুটি বেশি দরকার, আর কোনটা ছাড় দিতে হবে।
🔹 Distributed Database-এ এর প্রয়োগ
ধরি, নেটওয়ার্কে সমস্যা হলো (Partition ঘটল)। তখন তোমাকে ঠিক করতে হবে:
-
CP (Consistency + Partition tolerance)
-
নেটওয়ার্ক সমস্যা হলেও ডেটা সব নোডে একই রাখবে।
-
কিন্তু Availability কমে যাবে; ইউজার হয়তো কিছু সময় রেসপন্স পাবে না।
-
উদাহরণ: HBase, MongoDB (এক্সট্রা কনফিগ সহ), Redis Sentinel mode
-
ব্যবহার হয়: Banking system, payment gateway (এখানে ডেটার মিল না থাকলে বড় সমস্যা হবে)।
-
-
AP (Availability + Partition tolerance)
-
নেটওয়ার্ক সমস্যা হলেও সবসময় রেসপন্স পাবে।
-
তবে Consistency কমে যেতে পারে; কিছু সময়ের জন্য আলাদা নোডে আলাদা ডেটা দেখা যেতে পারে (eventual consistency)।
-
উদাহরণ: Cassandra, DynamoDB, CouchDB
-
ব্যবহার হয়: Social Media, E-commerce site (একটু mismatch হলেও চলবে, কিন্তু সাইট বন্ধ থাকা চলবে না)।
-
-
CA (Consistency + Availability)
-
Consistency আর Availability দুইটাই রাখা সম্ভব।
-
কিন্তু Partition tolerance রাখা যাবে না (মানে, নেটওয়ার্ক সবসময় ঠিক আছে বলে ধরা হয়)।
-
আসলে বাস্তব Distributed System-এ নেটওয়ার্ক failure হবেই, তাই pure CA system প্রায় অসম্ভব।
-
উদাহরণ: সাধারণ single-node relational DB (MySQL, PostgreSQL)
-
🔹 সুবিধা ও অসুবিধা
সুবিধা
-
CAP থিওরি আমাদের System Design-এ বেছে নিতে সাহায্য করে — কোন জায়গায় Consistency বেশি দরকার, আর কোথায় Availability বেশি দরকার।
-
এর মাধ্যমে প্রকল্পভেদে সঠিক Database বা Architecture নির্বাচন সহজ হয়।
-
Developer দের বুঝতে দেয় যে Distributed System-এ সব পাওয়া সম্ভব না।
অসুবিধা
-
এটি অনেকটা high-level theoretical model; বাস্তবে Database-গুলো অনেক সময় মিশ্রিত approach ব্যবহার করে (যেমন eventual consistency)।
-
কখনো কখনো CAP থিওরি decision নিতে সহজ করে না, কারণ বাস্তবে latency, throughput, user-experience ইত্যাদিও গুরুত্বপূর্ণ ফ্যাক্টর।
-
Pure CA সিস্টেম বাস্তবে কাজ করে না, কারণ network partition অস্বাভাবিক কিছু নয়।
🔹 সহজ উদাহরণ
ধরো তুমি একটা Social Media বানালে –
-
যদি Consistency (C) দাও → সবাই একই post একসাথে দেখবে, কিন্তু অনেক সময় post লোড হতে দেরি হতে পারে।
-
যদি Availability (A) দাও → সবাই post দেখতে পাবে, কিন্তু কিছু user পুরোনো data দেখতে পারে।
-
যদি Partition Tolerance (P) না দাও → নেটওয়ার্কে সামান্য সমস্যা হলে সিস্টেমই ডাউন হয়ে যাবে।
তাই Facebook/Instagram এর মতো সিস্টেম সাধারণত AP (Availability + Partition tolerance) বেছে নেয়।
আর Bank system বেছে নেয় CP (Consistency + Partition tolerance)।
