CAP Theorem

আপনার দুটি ব্যাংক branch - Dhaka ও Chittagong। প্রতি মুহূর্তে দুজনে account balance sync রাখতে চান। হঠাৎ Dhaka-Chittagong-এর internet line কেটে গেল। দুটো option:

• (1) Consistency বজায় রাখুন - যতক্ষণ sync নেই, কাজ বন্ধ। সবাই অপেক্ষা করুক।
• (2) Availability বজায় রাখুন - দুই branch আলাদা চলুক। পরে sync করব।

এটাই CAP Theorem-এর core trade-off।

CAP Theorem কী?

CAP Theorem (Brewer's theorem, ২০০০) - distributed system-এ একসাথে তিনটির মধ্যে শুধু দুটি সম্পূর্ণভাবে guarantee করা যায়:

• Consistency (C): সব node সবসময় একই data return করবে।
• Availability (A): প্রতিটি request response পাবে (success বা failure)।
• Partition Tolerance (P): Network failure হলেও system চলবে।

কেন তিনটি একসাথে impossible?

Distributed system-এ network partition হবেই (cable cut, router fail, latency spike)। অর্থাৎ P non-negotiable। তাহলে আসল choice - partition-এর সময় C না A?

Partition-এর সময়

• Node A ও Node B-এর মধ্যে network broken।
• Client A-কে কিছু লিখলো।
• Client B-কে read করল।
• Choice 1 (CP): B response দেবে না - sync নেই, তাই wait/error।
• Choice 2 (AP): B পুরাতন data return করবে - কিন্তু respond তো করবে।

CP Systems - Consistency + Partition Tolerance

Partition-এ Consistency চান, Availability ছেড়ে দিন।

উদাহরণ

• Traditional RDBMS: PostgreSQL, MySQL (synchronous replication)।
• MongoDB: Default config-এ majority write - partition-এ minority side write reject।
• HBase: Strong consistency।
• Zookeeper: Coordination service - must be consistent।

Use case

• Banking ও finance।
• E-commerce inventory।
• Booking system।
• Where stale data = harm।

AP Systems - Availability + Partition Tolerance

Partition-এ Availability চান, Consistency relax করুন।

উদাহরণ

• Cassandra: Eventually consistent (tunable)।
• DynamoDB: Default eventual consistency।
• CouchDB।
• Riak।
• DNS: Probably internet-এর সবচেয়ে বড় AP system।

Use case

• Social media feed।
• Real-time chat।
• Like/View count।
• Where availability > perfect accuracy।

CA Systems - কেন আসলে নেই?

Theory-তে CA (Consistency + Availability, no Partition) আছে - কিন্তু বাস্তবে network partition অনিবার্য। তাই pure CA system মাত্র single-node DB। Distributed হলে P আবশ্যক - তাই pick CP বা AP।

বাস্তবে - Tunable Consistency

Modern সিস্টেম strict CP/AP-এ আবদ্ধ নয়। Per-operation choose করা যায়:

Cassandra Consistency Levels

• ONE: এক replica responded → AP-leaning।
• QUORUM: Majority responded → balanced।
• ALL: সব replica → CP-like।

DynamoDB

• Eventually consistent read: Default, fast।
• Strongly consistent read: Latency বেশি।

Triangle Visualization

Real distributed system-এ আপনি বাম পাশ (CP) বা ডান পাশ (AP) - top corner (CA) reachable না।

বাস্তব উদাহরণ

• Banking transfer: CP - partition-এ better wait than wrong।
• Facebook newsfeed: AP - slight delay OK, must show something।
• Amazon shopping cart: AP - শেষে reconcile।
• Stock trading: CP - wrong price = loss।
• Booking.com: Mostly CP - double booking nay।

CAP-এর সীমাবদ্ধতা - PACELC

CAP শুধু partition-এর কথা বলে। Normal-time-এ কী? PACELC সম্পূর্ণ চিত্র দেয় - পরের chapter-এ বিস্তারিত।

সাধারণ ভুল ধারণা

1. "তিনটিই একসাথে পাওয়া যায়": না - Brewer-এর প্রমাণিত theorem।
2. "CAP system permanently choose": Modern DB tunable - query-level choose করা যায়।
3. "P optional": না - distributed system-এ network partition অনিবার্য।
4. "CP > AP": ভুল - use case dependent।

Best Practices

• Use case define - তারপর CP/AP choose।
• Tunable consistency embrace - per-operation choose।
• Application-এ inconsistency handle - UI level-এ "syncing" indicator।
• Conflict resolution strategy - CRDT, last-write-wins, vector clock।
• CAP মুখস্থ করার চেয়ে partition-এ behavior বুঝুন।