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

মধ্যবর্তী পর্যায়

Consistency Model: কোন write কখন দেখা যায়

Consistency Models

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

আগে পড়ে নিনDatabase Replication: read replica, lag ও failover ↗

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

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

একাধিক consistency model তুলনা করুন
Read-your-writes চাহিদা চিহ্নিত করুন
Replica lag-এর user experience সামলান

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

ক্রেতা Laravel account-এ ঠিকানা বদলে success দেখলেন। পরের GET অন্য database replica থেকে পুরোনো ঠিকানা আনল। ক্রেতা ভাবলেন save হয়নি। অথচ primary-তে update আছে। কোন client কখন কোন version দেখবে, সেই চুক্তি এখানে অস্পষ্ট।

সহজ করে বুঝি

Consistency model হলো concurrent read ও write-এর দৃশ্যমান আচরণের প্রতিশ্রুতি। Linearizability প্রতিটি operation-কে invocation ও response-এর মাঝের এক মুহূর্তে কার্যকর হয়েছে বলে ব্যাখ্যা করতে দেয়। Eventual consistency বলে নতুন write বন্ধ হলে replicas শেষ পর্যন্ত মিলে যাবে; সঙ্গে সঙ্গে মিলবে বলে না। Read-your-writes নিজের সফল পরিবর্তন পরে দেখতে সাহায্য করে।

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

শাখা অফিসে ঠিকানা জমা দিলে কেন্দ্রীয় register বদলায়, কিন্তু অন্য শাখার photocopy পরে আসে। Update দেওয়া ব্যক্তিকে নতুন register দেখানো যায়, অন্য দর্শক অল্প পুরোনো copy দেখতে পারেন। তবে photocopy কবে পৌঁছাবে তার সীমা না থাকলে “শিগগির” কোনো মাপযোগ্য guarantee নয়।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

একাধিক consistency model তুলনা করুন

Diagram-এর text flow দেখুন

flowchart LR
 A[Account update] --> P[(Primary)]
 P -->|Async replication| R[(Replica)]
 B[Immediate own read] --> P
 C[Catalog read] --> R

Write primary-তে যায় এবং commit ফেরে। Replication arrow asynchronous হওয়ায় কিছুক্ষণ replica পিছিয়ে থাকে। Immediate own read primary-তে দিলে ওই path stale নয়। Catalog-এর মতো কম সংবেদনশীল read replica-তে যেতে পারে। Route ভেদে contract আলাদা করা হয়েছে।

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

Laravel database configuration-এ read/write connection আছে ধরে নিন। একই request-এর sticky option পরের HTTP request-এ session guarantee দেয় না। Account endpoint-এ primary ব্যবহার করার এই fragment authenticated user-এর নিজস্ব record ফেরায়।

use Illuminate\Support\Facades\DB;

$userId = $request->user()->id;
$updated = DB::connection('mysql')->table('users')
    ->where('id', $userId)
    ->update(['shipping_city' => $validated['shipping_city']]);

$account = DB::connection('mysql')->table('users')
    ->useWritePdo()
    ->where('id', $userId)
    ->first(['id', 'shipping_city']);

return response()->json([
    'account' => $account,
    'read_policy' => 'primary',
]);

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

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

Primary reads সহজে নিজের update দেখায় কিন্তু primary-এর load বাড়ায়। Replica বেশি read capacity দেয়, কিন্তু lag সামলাতে UI এবং routing policy লাগে। Price বা stock confirmation-এ পুরোনো value ক্ষতি করতে পারে; recommendation count-এ সামান্য staleness গ্রহণযোগ্য হতে পারে।

সাধারণ ভুল

Eventual মানে নির্দিষ্ট এক সেকেন্ডে মিলে যাবে বলা।
Laravel sticky-কে cross-request consistency ভাবা।
সব endpoint-এ একই consistency প্রয়োজন ধরে নেওয়া।

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

Linearizability আর serializability এক বিষয় নয়: প্রথমটি operation-এর real-time order নিয়ে, দ্বিতীয়টি transaction execution-এর equivalent serial history নিয়ে। Database isolation নাম দেখে distributed client-এর observable behavior অনুমান করবেন না। Failover ও multi-region routing আলাদা পরীক্ষা করুন।

Replica replication সাময়িক থামিয়ে address update দিন। Account page এবং public profile endpoint-এর ফল তুলনা করুন। Contract লিখুন: account confirmation primary দেখবে; public profile বিলম্বিত হতে পারবে। Product manager-এর অনুমোদন নিয়ে stale window ও fallback latency মাপুন।

মনে রাখুন

Consistency একটি observable contract।
Read routing correctness-এর অংশ।
Own write দেখার প্রয়োজন আলাদা করে লিখুন।

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

Cart total, product review count ও password reset status-এর জন্য consistency policy বেছে নিন। পুরোনো read হলে ব্যবহারকারীর কী ক্ষতি হবে তা দিয়ে সিদ্ধান্ত সমর্থন করুন।

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

1. Eventual কি immediate?

না। নতুন update বন্ধ হলে convergence আশা করে; কতক্ষণ লাগবে আলাদা bound ছাড়া জানা যায় না।

2. সব read primary হলে লাভ?

সাম্প্রতিক primary data পাওয়া সহজ হয়, তবে capacity ও দূরবর্তী latency-এর মূল্য দিতে হয়।

3. Sticky কতক্ষণ?

Laravel-এর documented sticky behavior একই request cycle-এর write-এর পরে read-এর জন্য; browser session জুড়ে নয়।

4. Linearizability কি transaction isolation?

দুটি আলাদা model। একটি real-time operation order, অন্যটি transaction interleaving বিচার করে।

5. কোথায় eventual মানায়?

যেখানে সাময়িক পুরোনো ফল গ্রহণযোগ্য এবং convergence দেখা যায়; financial authorization-এ অন্ধভাবে নয়।

এই পাঠের কুইজ

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

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

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

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

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