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

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

PACELC: consistency, latency ও replication-এর সমন্বয়

PACELC Theorem

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

আগে পড়ে নিনCAP Theorem: partition-এর সময় consistency ও availability ↗

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

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

স্বাভাবিক সময়ের consistency খরচ বুঝুন
Latency ও replication সম্পর্ক দেখুন
Endpoint অনুযায়ী replication policy নিন

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

ঢাকা থেকে লেখা review Singapore ও Europe replica-তে পৌঁছানোর অপেক্ষা করে। Network ভাঙেনি, তবু submit ধীর। Team CAP পড়ে ভেবেছিল partition না হলে কোনো consistency trade-off নেই। আসলে দূরের acknowledgment-এর সময় স্বাভাবিক request-ও বহন করে।

সহজ করে বুঝি

PACELC বলে partition হলে availability বনাম consistency, else অর্থাৎ স্বাভাবিক সময়ে latency বনাম consistency বিবেচনা করতে হয়। এটি CAP-এর বিকল্প প্রমাণ নয়; design বোঝার framework। দূরের replica confirm না করা পর্যন্ত write ফেরত না দিলে অপেক্ষা বাড়ে, কিন্তু acknowledgment-এর অর্থ শক্তিশালী হতে পারে।

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

প্রতিটি invoice courier-এ দুই শাখায় যাচাই করিয়ে receipt দিলে তথ্য মেলে, অপেক্ষা বাড়ে। স্থানীয় receipt দিয়ে পরে copy পাঠালে দ্রুত হয়, কিন্তু অন্য শাখা কিছুক্ষণ পুরোনো তথ্য দেখে। শাখার দূরত্ব না কমলে শুধু cashier দ্রুত করলেই এই সময় মুছে যায় না।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

স্বাভাবিক সময়ের consistency খরচ বুঝুন

Diagram-এর text flow দেখুন

flowchart LR
 C[Laravel Client] --> P[Primary]
 P -->|Synchronous acknowledgment| R[Remote Replica]
 R -->|Ack| P
 P -->|Commit response| C

Client primary-তে write পাঠায়। Policy অনুযায়ী primary remote acknowledgment-এর অপেক্ষা করে। Replica উত্তর দিলে commit response ফেরে। প্রথম arrow-এর processing দ্রুত করলেও মাঝের network round trip latency budget-এর অংশ থাকে।

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

Laravel app-এ database-এর replication durability policy সাধারণ query option নয়; database administrator সেটি configure করেন। নিচের fragment read endpoint-এ freshness requirement স্পষ্ট করে। Database connection names primary ও reporting আগে configure করা আছে।

use Illuminate\Support\Facades\DB;

$requiresFreshData = $request->routeIs('account.balance');
$connection = $requiresFreshData ? 'primary' : 'reporting';
$started = hrtime(true);
$balance = DB::connection($connection)->table('account_summaries')
    ->where('user_id', $request->user()->id)
    ->first(['amount_minor', 'updated_at']);

logger()->info('summary.read', [
    'connection' => $connection,
    'duration_ms' => (hrtime(true) - $started) / 1_000_000,
]);
return response()->json(['summary' => $balance]);

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

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

Local read latency কমায় এবং regional resilience দেয়, কিন্তু stale summary ব্যাখ্যা করতে হয়। Global synchronization correctness সহজ করতে পারে, তবু long-tail latency ও cross-region cost বাড়ে। Balance authorization-এর সঙ্গে reporting chart-এর freshness requirement এক করবেন না।

সাধারণ ভুল

PACELC-কে সব implementation-এর নির্ভুল চার-অক্ষরের label ভাবা।
গড় latency দেখে দূরের replica-এর tail delay বাদ দেওয়া।
Primary read করলেই synchronous replication আছে ধরে নেওয়া।

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

Durability, isolation এবং visibility পৃথক guarantee। Replica acknowledgment disk flush বোঝায় কি শুধু receive বোঝায়, database documentation দিয়ে দেখুন। Network distance-এর নিচের সীমা application caching দিয়ে সব write-এ অতিক্রম করা যায় না।

একই endpoint primary ও reporting connection-এ চালিয়ে p50 এবং p99 মাপুন। Update-এর পরে stale response কতক্ষণ দেখা যায় লিখুন। এটি আপনার পরিবেশের পরীক্ষা, সাধারণ benchmark নয়। Product অনুযায়ী latency ও stale tolerance একসঙ্গে গ্রহণযোগ্য হতে হবে।

মনে রাখুন

Partition ছাড়াও coordination-এর খরচ আছে।
Acknowledgment-এর অর্থ যাচাই করুন।
Endpoint-এর freshness contract লিখুন।

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

Financial authorization এবং weekly sales report-এর জন্য latency ও consistency budget আলাদা করুন। প্রতিটির গ্রহণযোগ্য stale window উল্লেখ করুন।

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

1. Else অংশ কী?

Partition না থাকলেও replica coordination latency ও consistency-তে প্রভাব ফেলে; সেই স্বাভাবিক অবস্থার সিদ্ধান্ত।

2. এটি CAP বাতিল করে?

না। Partition-কালের CAP সীমা রেখেই স্বাভাবিক সময়ের trade-off আলোচনা করে।

3. দ্রুত response মানেই নিরাপদ?

না। কোন replica কখন update জানবে এবং failure-এ কী হারাতে পারে বুঝতে হয়।

4. এক configuration সবার জন্য?

দরকার নেই। Critical write এবং stale-tolerant reporting আলাদা policy নিতে পারে।

5. কী মাপবেন?

Tail latency, replication lag এবং stale read-এর business impact; শুধু mean response time যথেষ্ট নয়।

এই পাঠের কুইজ

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

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

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

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

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