পাঠ্যক্রম খুলুন

প্রাথমিক পর্যায়

CAP Theorem: partition-এর সময় consistency ও availability

CAP Theorem

এই পাঠের কুইজ ↓৫ মিনিট পড়াPHP 8.3+ · Laravel 12

আগে পড়ে নিনPartial Failure: কিছু component সচল, কিছু অনিশ্চিত ↗Consistency Model: কোন write কখন দেখা যায় ↗

এই পাঠের সূচিপত্র

এই পাঠে যা শিখবেন

CAP-এর নির্দিষ্ট অর্থ বুঝুন
Partition-এর সময় write policy বেছে নিন
Business invariant দিয়ে সিদ্ধান্ত নিন

সমস্যা দিয়ে শুরু

টিকিটের শেষ seat দুই region-এ বিক্রি হচ্ছে। Network বিভক্ত হওয়ায় দুই region মজুতের খবর আদানপ্রদান করতে পারছে না। উভয় region স্থানীয় stock দেখে success দিলে একটি seat দুজনের নামে যাবে। সব request চালু রাখা আর একটিমাত্র সত্য রাখা একসঙ্গে সম্ভব হচ্ছে না।

সহজ করে বুঝি

CAP theorem asynchronous distributed model-এ network partition চলার সময় linearizable consistency এবং প্রতিটি non-failing node-এ availability একসঙ্গে নিশ্চিত করা যায় না বলে। এখানে availability মানে প্রত্যেক request অবশেষে response পাবে; marketing uptime নয়। Partition না থাকলে এই theorem সর্বক্ষণ দুইটি feature বেছে নিতে বলে না।

পরিচিত একটি উপমা

দুই কাউন্টারের একটি আসনের shared খাতা দেখার পথ বন্ধ। একটি কাউন্টার বিক্রি বন্ধ রাখলে double booking এড়ায়। উভয়কে স্বাধীন বিক্রি করতে দিলে পরে refund করতে হতে পারে। উপমায় মানুষ ফোন করতে পারে; প্রকৃত partition-এ সেই বিকল্প যোগাযোগও অপ্রাপ্য ধরে বিচার করতে হয়।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

CAP-এর নির্দিষ্ট অর্থ বুঝুন

Diagram-এর text flow দেখুন

flowchart LR
 U[Buyer A] --> A[Region A]
 V[Buyer B] --> B[Region B]
 A -.->|Partition| B
 A --> L[Single seat authority]
 B --> X[Reject or wait]

প্রথম দুই arrow স্বাধীন request দেখায়। বিচ্ছিন্ন region-গুলো একই authority নিশ্চিত করতে পারছে না। Seat-এর write authority A-তে থাকায় B বিক্রি বন্ধ রাখে। Reject বা bounded wait ব্যবসার সিদ্ধান্ত; এটি CAP availability ত্যাগের ব্যবহারিক উদাহরণ।

PHP ও Laravel-এ প্রয়োগ

Controller fragment-এ seat reservation এক authoritative PostgreSQL/MySQL database-এ রাখা। unique booking constraint এবং payment expiration আলাদা দরকার। Database unreachable হলে অন্য স্বাধীন database-এ একই seat লিখে success ফেরানো হচ্ছে না।

use Illuminate\Support\Facades\DB;

$reservation = DB::transaction(function () use ($seatId, $userId) {
    $seat = DB::table('seats')->where('id', $seatId)
        ->lockForUpdate()->first();
    abort_unless($seat && $seat->status === 'available', 409);
    DB::table('seats')->where('id', $seatId)
        ->update(['status' => 'reserved']);
    return DB::table('reservations')->insertGetId([
        'seat_id' => $seatId,
        'user_id' => $userId,
        'created_at' => now(),
    ]);
});
return response()->json(['reservation_id' => $reservation], 201);

এটি PHP 8.3+ ও Laravel 12-এর শিক্ষামূলক fragment; সম্পূর্ণ application নয়। সংশ্লিষ্ট route-এ authentication ও resource authorization প্রয়োগ করতে হবে। নিচের অনুশীলনে failure ইচ্ছা করে তৈরি করুন; শুধু সফল response দেখে correctness ধরে নেবেন না।

সুবিধা, সীমাবদ্ধতা ও trade-off

Reservation বন্ধ থাকলে সাময়িক revenue হারাতে পারেন, কিন্তু double booking হয় না। Feed reaction-এর মতো merge করা যায় এমন data-তে local acceptance ভালো হতে পারে। একই product-এর seat, review এবং analytics ভিন্ন partition policy পেতে পারে।

সাধারণ ভুল

CAP-এর C-কে ACID consistency বলা।
Partition tolerance একটি checkbox বন্ধ করলেই network failure যাবে ভাবা।
CP বা AP label দিয়ে পুরো database-এর সব operation ব্যাখ্যা করা।

আরও একটু গভীরে

Timeout ও failure detector partition নিশ্চিত প্রমাণ করে না। Minority write reject করলেও stale read ফেরানো হতে পারে; read এবং write contract আলাদা লিখুন। Availability-এর formal অর্থ আর মাসিক SLO আলাদা পরিমাপ।

দুটি API instance থেকে একই seat কিনুন এবং database link একটি instance-এ বন্ধ করুন। সফল reservation সংখ্যা এক হওয়া চাই। Error path যেন payment charge না করে তা যাচাই করুন। পরে link ফিরলে rejected user-এর জন্য নতুন availability check হবে।

মনে রাখুন

CAP partition-কালের সীমা ব্যাখ্যা করে।
Seat invariant আগে লিখুন।
Operation অনুযায়ী availability সিদ্ধান্ত নিন।

নিজে চেষ্টা করুন

Seat booking এবং like counter-এর partition policy লিখুন; কোন ক্ষতি undo করা যায় এবং কোনটি যায় না তুলনা করুন।

নিজের বোঝা যাচাই করুন

1. CAP-এর C কী?

Linearizable behavior; শুধু foreign key ঠিক থাকা নয়। Real-time order এখানে গুরুত্বপূর্ণ।

2. P বাদ দেওয়া যায়?

বাস্তব network-এ partition ঘটতে পারে। Single-node design বেছে নিতে পারেন, কিন্তু distributed link-কে অব্যর্থ ঘোষণা করতে পারেন না।

3. সব সময় দুইটি বাছতে হয়?

না। Partition চলার সময় যে guarantee একসঙ্গে অসম্ভব, সেটিই theorem-এর মূল সীমা।

4. Booking কেন বন্ধ?

একমাত্র seat-এর invariant রক্ষা করতে অন্য region-এর অনিশ্চিত write বন্ধ করা হয়েছে।

5. Like-এ একই policy?

প্রয়োজন নেই। Merge করা reaction-এ সাময়িক বিচ্যুতি গ্রহণযোগ্য হলে local acceptance মানায়।

এই পাঠের কুইজ

এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।

এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।

জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।

সব বিষয় মিলিয়ে অনুশীলন করুন →

অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।