Caching strategy: cache-aside, write-through, write-back
Caching সিস্টেম দ্রুত করার সবচেয়ে সস্তা উপায়। মূল strategy, কোনটি কখন মানায় এবং কঠিন অংশ invalidation ও stampede জেনে নিন।
Cache হলো দ্রুত জায়গায় (সাধারণত memory) data-র একটি কপি, যাতে database query-র মতো ধীর কাজ বারবার করতে না হয়। Write-এর তুলনায় read অনেক বেশি হলে এটি সবচেয়ে কাজে লাগে।
Strategy
Cache-aside (lazy loading)। App আগে cache দেখে। না পেলে (miss) database থেকে এনে cache-এ রাখে। সহজ এবং সবচেয়ে প্রচলিত। যে data চাওয়া হয় শুধু সেটাই cache হয়।
Write-through। প্রতিটি write একসাথে cache ও database-এ যায়। Read সবসময় সতেজ, কিন্তু write ধীর।
Write-back (write-behind)। আগে cache-এ লিখে পরে batch করে database-এ সেভ করা। write খুব দ্রুত, কিন্তু সেভ হওয়ার আগে cache মরলে data হারাতে পারে।
Eviction
Memory সীমিত, তাই কিছু সরাতে হবে। LRU সবচেয়ে বেশি সময় ধরে ব্যবহার না হওয়াটি সরায়। LFU সবচেয়ে কম ব্যবহৃতটি সরায়। TTL নির্দিষ্ট সময় পর মুছে দেয়।
কঠিন সমস্যাগুলো
- Invalidation। মূল data বদলালে পুরোনো cache আপডেট বা মুছতে হবে। নিরাপদ ডিফল্ট: ছোট TTL আর write-এর সময় key মুছে দেওয়া।
- Cache stampede। জনপ্রিয় key মেয়াদ শেষে একসাথে হাজারো request database-এ আঘাত করে। সমাধান: lock দিয়ে একজনই নতুন করে বানাবে, TTL-এ random jitter, বা মেয়াদ শেষের আগেই refresh।
- Cold start। খালি cache সব traffic database-এ পাঠায়। বড় launch-এর আগে cache গরম করুন।
Cache কোথায় থাকে
Browser, CDN, reverse proxy, application memory, আর Redis বা Memcached-এর মতো shared store। প্রতিটি স্তর পরের স্তরের চাপ কমায়।
মূল কথা: cache-aside আর TTL দিয়ে শুরু করুন, read-heavy data cache করুন, আর প্রথম দিন থেকেই invalidation-এর পরিকল্পনা রাখুন।
System Design সিরিজের 5 নম্বর পর্ব (মোট ১৫)। আগের পর্ব: Load balancer: কী কাজ করে ও algorithm বাছাই.
