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 বুঝুন।