Caching Strategy: read-through ও write-through-এর পার্থক্য
Read-Through, Write-Through, and Write-Behind Caching
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Read-through, write-through ও write-behind
- Cache-aside-এর সঙ্গে দায়িত্বের পার্থক্য
- Laravel application-এ source of truth নির্বাচন
সমস্যা দিয়ে শুরু
Product update সফল হওয়ার পরে page পুরোনো নাম দেখাচ্ছে। Team বলে cache-এও write করা হয়েছিল। কিন্তু database commit ব্যর্থ হলে cache কোন সত্য দেখাবে? Cache strategy শুধু কোন method ডাকা হবে তা নয়; read miss কে পূরণ করে, write কখন durable হয় এবং failure-এ কোন copy authoritative থাকবে তা নির্ধারণ করে।
সহজ করে বুঝি
Read-through-এ cache abstraction miss পেলে source পড়ে data ফেরায়। Cache-aside-এ application নিজে miss সামলায়। Write-through abstraction সাধারণত write path-এই backing store ও cache update coordinate করে; exact guarantee implementation-এর contract। Write-behind আগে cache/buffer-এ গ্রহণ করে পরে asynchronous ভাবে database-এ লেখে। Durable buffer, replay ও ordering না থাকলে acknowledged write হারাতে পারে। Laravel Cache::remember application-level cache-aside helper, automatic database-coherent write-through system নয়।
পরিচিত একটি উপমা
দোকানের counter তালিকা গুদামের খাতা দেখে পূরণ করা cache-aside-এর মতো। একটি central clerk যদি তালিকা ও খাতা দুটিই manage করেন সেটি read/write-through abstraction-এর কাছাকাছি। Counter-এ বিক্রি লিখে সন্ধ্যায় main ledger update করলে write-behind; counter খাতা হারালে হিসাবও হারায় যদি durable copy না থাকে।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD C[Client write] --> A[Application] A --> D[(Authoritative Database)] D -->|Commit succeeds| I[Invalidate cache] I --> K[(Redis)] R[Later read miss] --> D D -->|Refill| K
এখানে write-behind নয়, database-first invalidation দেখানো হয়েছে। Commit-এর পরে cache key মুছে পরের read-এ refill হয়। এতে cache durable write-এর authority নয়। তবে commit ও invalidation-এর মাঝের crash এবং stale reader refill race এখনো আছে। কঠোর freshness লাগলে versioning বা durable invalidation workflow দরকার।
PHP ও Laravel-এ প্রয়োগ
এই service-method fragment authorized product update action-এর অংশ। Product model এবং validated $data ধরা হয়েছে। Redis store configured এবং update request authorization আগে করতে হবে। DB commit-এর পরে forget ব্যর্থ হলে log/recovery policy লাগবে; এই snippet cross-system atomicity দেয় না।
use App\Models\Product;
use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\DB;
$product = DB::transaction(function () use ($productId, $data) {
$product = Product::query()->findOrFail($productId);
$product->update($data);
return $product;
});
Cache::store('redis')->forget("product:v1:{$product->id}");
return $product;সুবিধা, সীমাবদ্ধতা ও trade-off
Cache-aside incremental adoption সহজ করে, কিন্তু caller-দের invalidation discipline লাগে। Through abstraction policy centralize করতে পারে, implementation complexity বাড়ে। Write-behind write latency কমায় এবং batching দেয়, তবে durability, ordering ও conflict resolution কঠিন। Account balance-এর মতো data-তে শুধু cache acknowledgement-কে final commit বলা বিপজ্জনক। Less-critical counters-এ acceptable loss budget থাকলে আলাদা সিদ্ধান্ত হতে পারে।
সাধারণ ভুল
- Cache::put ও DB save পরপর ডাকলেই atomic write-through বলা।
- Write-behind queue memory-only রেখেও durable acknowledgement দেওয়া।
- Cache miss-এ unbounded database query চালানো।
আরও একটু গভীরে
Write amplification বিচার করুন: একটি product update একাধিক representation, search result ও category cache বদলাতে পারে। Direct update সব key enumerate করতে কঠিন হলে versioned namespace বা event-driven invalidation উপযোগী। Outbox event durable handoff দিতে পারে, তবে consumer lag-এর stale window থাকবে। Strategy evaluation-এ cache availability, database fallback ও concurrent readers একসঙ্গে ধরে failure timeline লিখুন।
মনে রাখুন
Cache strategy ownership ও acknowledgement boundary নির্ধারণ করে। Source of truth আগে ঠিক করুন। Through শব্দ দেখে consistency guarantee অনুমান না করে implementation contract পড়ুন।
নিজে চেষ্টা করুন
Product description, inventory stock ও analytics counter-এর জন্য আলাদা strategy বেছে নিন। Cache write সফল কিন্তু database fail এবং database commit সফল কিন্তু invalidation fail—দুটি timeline লিখে user কী দেখবে ব্যাখ্যা করুন।
নিজের বোঝা যাচাই করুন
1. Read-through আর cache-aside একই?
দুটিতে miss source থেকে পূরণ হতে পারে, কিন্তু দায়িত্ব আলাদা। প্রথমটিতে abstraction source access manage করে, দ্বিতীয়টিতে application তা করে।
2. remember write-through?
না। এটি read miss callback চালিয়ে value রাখে। Eloquent update-এর সঙ্গে automatic coherence বা transaction যোগ করে না।
3. Write-behind-এর প্রধান ঝুঁকি?
Acknowledged data backing store-এ পৌঁছানোর আগেই হারাতে বা reorder হতে পারে। Durable buffer ও recovery contract অপরিহার্য।
4. Database-first invalidation নিখুঁত?
না। Crash gap এবং concurrent stale refill থাকতে পারে। Freshness requirement অনুযায়ী version বা reliable invalidation দরকার।
5. সব data-তে এক strategy?
না। Money, inventory ও view counter-এর loss/staleness tolerance আলাদা। Business requirement অনুযায়ী boundary বেছে নিতে হবে।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।