Day 30 — CAP Theorem — Distributed System-এর সবচেয়ে গুরুত্বপূর্ণ সত্য 🎓

এতদিনে তো বুঝেই গেছেন যে Distributed System একটা Nightmare! এখানে কখন কী হয় কেউ সহজে Predict করতে পারে না। আরেকটা বিষয় হলো—এখানে কোনো Decision-ই ভুল না, আবার সব Decision পুরোপুরি সঠিকও না।

এখানে থেকেই Eric Brewer ২০০০ সালের দিকে বলেছিলেন যে—একসাথে Consistency, Availability, এবং Partition Tolerance—এই ৩টি জিনিসের Guarantee দেওয়া অসম্ভব!

২ বছর পর এই ধারণাটি Formally Proved-ও হয়ে যায়, এবং এটি CAP Theorem নামে পরিচিতি পায়।

আসলে Eric Brewer কি ঠিক বলেছিলেন? আসুন এই বিষয়গুলো নিয়ে আলোচনা করি।

CAP Theorem কী?

CAP Theorem হলো Consistency, Availability, এবং Partition Tolerance-এর সংক্ষিপ্ত রূপ।

• C — Consistency: Consistency-র মানে হচ্ছে যাই হয়ে যাক না কেন, সব জায়গায় ডাটা একই থাকবে। একটা ডাটা যদি এক জায়গায় আপডেট হয়, তবে সাথে সাথেই বাকি সব সার্ভারেও একই আপডেট হয়ে যাবে।
• A — Availability: Availability-র মানে হচ্ছে সিস্টেমে রিকোয়েস্ট পাঠালে সিস্টেম সবসময় রেসপন্স দেবে। এখানে রেসপন্স দেওয়া ডাটাটি Updated হোক বা Stale (পুরানো) ডাটা হোক।
• P — Partition Tolerance: Partition Tolerance-এর মানে হলো দুটো নোডের মধ্যে নেটওয়ার্ক ড্রপ বা ব্রেকডাউন হলেও সিস্টেম কাজ করা বন্ধ করবে না। অর্থাৎ নোডগুলোর মধ্যে নেটওয়ার্ক বিচ্ছেদ ঘটলেও পুরো সিস্টেম সচল থাকবে।

Network Partition

Real-world distributed system-এ Network Failure কখনো পুরোপুরি এড়ানো সম্ভব না। দুটো সার্ভার নোডের মধ্যে যেকোনো সময় কেবল কাটা পড়তে পারে বা নেটওয়ার্ক কানেকশন লস্ট হতে পারে। অর্থাৎ সিস্টেমে Partition হওয়াটা অত্যন্ত স্বাভাবিক ব্যাপার। তাই Partition Tolerance (P) বাদ দেওয়ার কোনো উপায় নেই!

যেহেতু Partition Tolerance (P) সবসময় বজায় রাখতেই হবে, তাই আপনার সামনে মূল চয়েস থাকে দুটি: হয় আপনাকে Consistency (C) বেছে নিতে হবে, না হয় Availability (A) বেছে নিতে হবে। অর্থাৎ সহজ কথায়—CP নাকি AP?

CP System: Consistency বেছে নিলে 🔒

CP সিস্টেমে যাই হয়ে যাক না কেন, ইউজারকে ভুল ডাটা দেখানো যাবে না! নেটওয়ার্ক সমস্যা থাকলে ইউজারকে প্রয়োজনে Error বা "Try Again" মেসেজ দেখাবে, তাও ভুল বা অসামঞ্জস্যপূর্ণ ডাটা দেখানো যাবে না।

উদাহরণ হিসেবে ব্যাংক অ্যাকাউন্টের ব্যালেন্সের কথা বলা যেতে পারে। ভুল ব্যালেন্স দেখানোর চেয়ে ইউজারকে সাময়িক সময়ের জন্য Error দেখানো শতগুণ শ্রেয়! এই ধরনের ক্ষেত্রে CP System-ই হলো একমাত্র সঠিক চয়েস।

AP System: Availability বেছে নিলে ⚡

CP সিস্টেমে ফোকাস থাকে ডাটার নিখুঁত সঠিকতার ওপর। কিন্তু AP সিস্টেমে নীতিটা পুরোপুরি উল্টো! এখানে মূল কথা হলো—যাই হয়ে যাক না কেন ইউজারকে স্ক্রিনে কিছু না কিছু দেখাতে হবে, সিস্টেম ডাউন করা যাবে না! প্রয়োজনে ২ সেকেন্ড আগের পুরানো (Stale) ডাটা দেখাবে, কিন্তু কোনো Error দেখানো যাবে না। এই ধরনের সিস্টেমকে Eventually Consistent System-ও বলা হয়।

উদাহরণ হিসেবে সোশ্যাল মিডিয়ার লাইক কাউন্টের কথা ধরা যাক। ইউজার পেজ রিফ্রেশ করলে ৪-৫ সেকেন্ড আগের লাইক সংখ্যা দেখালেও মহাভারত অশুদ্ধ হয়ে যাবে না, কিন্তু লাল রঙের সার্ভার এরর দেখলে ইউজার বিরক্ত হয়ে অ্যাপ ক্লোজ করে দেবে! ৪-৫ সেকেন্ড পর ব্যাকগ্রাউন্ডে ডাটা অটোমেটিক সিঙ্ক (Eventually Consistent) হয়ে যাবে।

Real-world Example: বাস্তব জীবনের ৩টি সিনারিও 🌍

১. Banking System (CP System) 🏦

Scenario: মনে করুন, একটি ব্যাংকের দুটি আলাদা লোকেশনে দুটি ডাটাবেস সার্ভার আছে। একজন কাস্টমারের অ্যাকাউন্টে ১,০০০ টাকা জমা আছে। তিনি এটিএম বুথ থেকে ৮০০ টাকা ক্যাশ আউট করলেন। সার্ভার-১ ট্রানজেকশন প্রসেস করে ব্যালেন্স বানিয়ে দিল ২০০ টাকা।

ঠিক সেই মুহূর্তে দুটি ডাটাবেস সার্ভারের মধ্যকার নেটওয়ার্ক ক্যাবলটি বিচ্ছিন্ন হয়ে গেল! সার্ভার-১ জানে নতুন ব্যালেন্স ২০০ টাকা, কিন্তু সার্ভার-২ কিন্তু এখনো ভাবছে অ্যাকাউন্টে ১,০০০ টাকাই আছে!

এখন কাস্টমার যদি চটজলদি অন্য একটি বুথে গিয়ে আবার ৫০০ টাকা উইথড্র করার রিকোয়েস্ট পাঠান যা গিয়ে পড়ল সার্ভার-২ এর ওপর—তখন কী হবে?

Problem: সার্ভার-২ যদি রিকোয়েস্ট একসেপ্ট করে ফেলে, তবে কাস্টমার ২০০ টাকা থাকা সত্ত্বেও মোট ১৩০০ টাকা তুলে ফেলবেন! আর্থিক লেনদেনে সামান্য ভুলের খেসারত কিন্তু অনেক বড়। ভুল ডাটা দেখানোর চেয়ে সাময়িক সার্ভিস বন্ধ থাকা অনেক ভালো।

Solution: ব্যাংকিং সিস্টেম সবসময় Consistency + Partition Tolerance (CP) বেছে নেয়। সার্ভারগুলোর মধ্যে নেটওয়ার্ক বিচ্ছেদ ঘটলে সিস্টেম ইউজারকে সোজা বলে দেবে: "দুঃখিত, এই মুহূর্তে আপনার ট্রানজেকশন প্রসেস করা যাচ্ছে না। অনুগ্রহ করে কিছুক্ষণ পর আবার চেষ্টা করুন।" ভুল টাকা কেটে নেওয়ার চেয়ে এই এরর মেসেজটাই শতগুণ নিরাপদ!

২. E-commerce Shopping Cart (AP System) 🛒

Scenario: আমাজন বা দারাজে আপনি একটা পছন্দের জুতো কার্টে (Cart) অ্যাড করলেন। আপনার রিকোয়েস্টটি একটা সার্ভারে গিয়ে কার্ট আপডেট করল। কিন্তু নেটওয়ার্ক ঝামেলার কারণে সেই আপডেটটি অন্য সার্ভারে পৌঁছাতে সামান্য দেরি হলো। এবার আপনি পেজটা রিফ্রেশ করলেন আর রিকোয়েস্টটি গিয়ে পড়ল দ্বিতীয় সার্ভারে।

আপনি হয়তো ১-২ সেকেন্ডের জন্য দেখতে পেলেন: "Your cart is empty." অথচ অন্য সার্ভার জানে আপনি কার্টে জুতো অ্যাড করেছেন!

Problem and Solution: এখানে ডাটা সাময়িকভাবে ইনকনসিস্টেন্ট, কিন্তু ব্যাংকের মতো এখানে কি কোটি টাকার ক্ষতি হয়ে গেছে? একদম না! আমাজন যদি কার্ট সিঙ্ক হয়নি বলে পুরো সাইট ডাউন করে দেয়, তবে ইউজার কেনাকাটাই ছেড়ে দেবে!

তাই ই-কমার্স কার্টের ক্ষেত্রে Availability + Partition Tolerance (AP) বেছে নেওয়া হয়। ইউজারকে ব্রাউজ করতে দেওয়া হয়, কেনাকাটা চালিয়ে যেতে দেওয়া হয়। ২-৩ সেকেন্ড পর সার্ভার নিজেদের মধ্যে ডাটা সিঙ্ক করে নেয় (Eventual Consistency)।

৩. Social Media Likes (AP System) 📱

Scenario: ফেসবুকে একটা পোস্টে অলরেডি ১০,০০০ লাইক আছে। বাংলাদেশে বসে একজন ইউজার নতুন একটা লাইক দিলেন। বাংলাদেশ সার্ভার সাথে সাথে লাইক বানিয়ে দিল ১০,০০১। কিন্তু আন্তর্জাতিক ফাইবার অপটিক ক্যাবলে ঝামেলার কারণে ইউরোপের সার্ভার সাথে সাথে সেই আপডেট পেল না।

ইউরোপ থেকে একজন পেজ দেখে দেখছে 10,000 likes, আর বাংলাদেশ থেকে দেখছে 10,001 likes!

Solution: একটা লাইকের হিসাব ১ মিলিসেকেন্ডের মধ্যে পুরো পৃথিবীর সার্ভারে না পৌঁছালে কারও জীবন আটকে থাকবে না! কিন্তু ফেসবুক যদি লাইক সিঙ্ক করার জন্য পুরো দুনিয়ার ইউজারদের স্ক্রিন ব্লক করে রাখে, তবে ইউজার অ্যাপই ডিলেট করে দেবে।

তাই লাইক, ভিউ, শেয়ার বা ফলোয়ার কাউন্টের জন্য চোখ বন্ধ করে AP (Availability + Partition Tolerance) আর্কিটেকচার ব্যবহার করা হয়।

সংক্ষেপে মুখোমুখি তুলনা 📊

বটম লাইন

CAP Theorem মুখস্থ করবেন না—উপলব্ধি করুন। আপনার ডাটার জন্য কোনটা বেশি গুরুত্বপূর্ণ—Consistency নাকি Availability? Banking-এ Consistency, Social Media-তে Availability। Context বুঝে ডাটাবেস ও আর্কিটেকচার Select করুন।