Cache-aside: Laravel ও Redis-এ cache ব্যবহার
Cache-Aside with Laravel and Redis
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Cache-aside flow বাস্তবায়ন
- Redis store ও key design
- Invalidation এবং stampede-এর সীমা বোঝা
সমস্যা দিয়ে শুরু
হাজার user একই product page দেখছেন। প্রতিবার একই product query ও serialization চলছে। Database-এর কাজের বড় অংশ একই উত্তর বানানো। কিছুক্ষণ পুরোনো display data গ্রহণযোগ্য হলে cache কাজে লাগতে পারে। তবে checkout-এর price ও stock যাচাইয়ের একমাত্র source cache করা বিপজ্জনক।
সহজ করে বুঝি
Cache-aside pattern-এ application আগে cache পড়ে। Hit হলে cached value ফেরায়। Miss হলে authoritative store থেকে ডেটা পড়ে, cache-এ রাখে, তারপর response দেয়। TTL শেষ হলে value বাদ যায়। Cache হলো performance optimization; authoritative database-এর বিকল্প নয়।
Redis network-accessible cache store হিসেবে একাধিক Laravel instance-এর মধ্যে value share করতে পারে। Key-তে resource identity, representation version এবং প্রযোজ্য tenant/locale রাখুন। ব্যক্তিগত price বা permission-sensitive response public product key-তে রাখবেন না।
পরিচিত একটি উপমা
দোকানদার প্রতিবার গুদামে না গিয়ে counter-এর ছোট তালিকা থেকে জনপ্রিয় বইয়ের নাম ও বিবরণ বলেন। তালিকা দ্রুত, কিন্তু কিছুক্ষণ পুরোনো হতে পারে। বিক্রির সময় আসল stock খাতা দেখেই final সিদ্ধান্ত নেওয়া উচিত।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD
A[Laravel request] --> B{Redis cache hit?}
B -->|Yes| C[Return cached product]
B -->|No| D[(Read PostgreSQL)]
D --> E[Store value with TTL]
E --> C
F[Product update commits] --> G[Forget cache key]১. Stable key বানান। ২. Redis থেকে পড়ুন। ৩. Miss হলে bounded query চালান। ৪. TTL-সহ serialization-friendly data রাখুন। ৫. Product update commit হলে invalidate করুন। ৬. Hit ratio, miss latency ও stale-data behavior মাপুন।
PHP ও Laravel-এ প্রয়োগ
নিচের service-method fragment-এ Product model আছে ধরে নেওয়া হয়েছে। Redis server ও PhpRedis বা Predis client configured থাকতে হবে। Cache::remember miss-এর সময় সব concurrent request-এর query একা চালাবে—এ নিশ্চয়তা দেয় না।
use App\Models\Product;
use Illuminate\Support\Facades\Cache;
$productId = 42;
$key = "product:v1:{$productId}";
$data = Cache::store('redis')->remember(
$key,
now()->addMinutes(5),
fn () => Product::query()->findOrFail($productId)
->only(['id', 'name', 'description'])
);
return response()->json($data);সুবিধা, সীমাবদ্ধতা ও trade-off
Cache hit database work কমায়, কিন্তু memory, network ও stale-data risk যোগ করে। Short TTL stale window কমায়, miss বাড়ায়। Update-এর পরে Cache::store('redis')->forget($key) সাহায্য করে, কিন্তু concurrent stale reader আবার পুরোনো data fill করতে পারে। Strict consistency দরকার হলে versioning বা stronger coordination design করতে হবে।
সাধারণ ভুল
- Default cache store Redis ধরে নেওয়া; Laravel 12-এর default database হতে পারে।
- Commit-এর আগে invalidation করে stale read-এর race তৈরি করা।
- Cache outage-এ সব request একসঙ্গে database-এ পাঠানো।
- Tenant ID বা authorization context key থেকে বাদ দেওয়া।
আরও একটু গভীরে
Stampede হলে একই hot key miss-এ অনেক request database-এ যায়। Supported shared store-এ atomic lock নিয়ে double-check, bounded waiting ও TTL jitter ব্যবহার করতে পারেন। Lock lease query-এর চেয়ে আগে শেষ হলে আবার concurrency আসতে পারে। Cache failure-এর fallback ও DB protection policy আগেই লিখুন।
মনে রাখুন
- Cache-aside-এ application cache fill-এর দায়িত্ব নেয়।
- TTL এবং write invalidation দুটোই দরকার হতে পারে।
- Cache correctness guarantee requirement অনুযায়ী বিচার করুন।
নিজে চেষ্টা করুন
Product description বদলানোর একটি timeline আঁকুন: reader miss, writer commit, key forget, stale reader fill। কীভাবে পুরোনো value ফিরতে পারে? Checkout কেন database থেকে authoritative price নেবে?
নিজের বোঝা যাচাই করুন
1. Cache miss হলে কী হয়?
Application source database পড়ে এবং সাধারণত TTL-সহ cache পূরণ করে।
2. remember কি stampede আটকায়?
নিজে distributed single-flight guarantee দেয় না। Concurrent miss-এর জন্য আলাদা coordination লাগতে পারে।
3. Redis সবসময় Laravel default cache?
না। Configuration যাচাই করুন; explicit store বেছে নিলে example-এর উদ্দেশ্য পরিষ্কার থাকে।
4. Forget করলেই race শেষ?
না। আগে শুরু হওয়া stale reader পরে পুরোনো value লিখতে পারে।
5. Checkout stock শুধু cache থেকে নেব?
Overselling ঠেকাতে authoritative write path-এ transaction ও concurrency control দরকার।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।