Caching কৌশল — cache-aside, read-through, write-through আর write-back

১ · Cache কেন — latency, ডেটাবেসের ভার আর খরচ

একটি কাল্পনিক অনলাইন বাজারের কথা ভাবুন। প্রতিটি পণ্যের পাতা খুলতে ডেটাবেসে কয়েকটি query: নাম, দাম, স্টক আর রিভিউর গড়। সাধারণ দিনে সব ঠিক। ঈদের সেলের সন্ধ্যায় সেকেন্ডে দশ হাজার পাতা — ডেটাবেসের CPU পুরো ব্যস্ত, প্রতিটি query ধীর, আর ধীর query মানে আরও বেশি অপেক্ষমাণ connection. অথচ খেয়াল করুন: বেশিরভাগ মানুষ দেখছেন সবচেয়ে জনপ্রিয় কয়েকশো পণ্য, আর প্রতিবার উত্তর হুবহু এক। একই উত্তর বারবার ডেটাবেস থেকে বানানোর দরকার কী?

সমাধান cache: বারবার লাগা ডেটার একটি কপি দ্রুত memory-তে, সাধারণত Redis বা Memcached-এর মতো একটি key-value store-এ। চাওয়া জিনিস cache-এ পেলে hit, না পেলে miss — তখন মূল উৎস, অর্থাৎ ডেটাবেস। CDN-এর cache দেখেছেন পর্ব ১৭-এ; এই মডিউলের বিষয় application-এর নিজের cache, সার্ভিস আর ডেটাবেসের মাঝখানে।

তিনটি লাভ — নকশার ভাষায়

গড় latency-র সূত্র — CPU cache-এর AMAT-এর মতোই

প্রতিটি অনুরোধে আগে cache দেখা হয় (খরচ t_c); miss হলে তার ওপর ডেটাবেসের খরচ t_db যোগ হয়। Hit ratio h আর সেকেন্ডে মোট পড়া R হলে:

এটি Computer Architecture-এর AMAT — hit time + miss rate × miss penalty — হুবহু একই সূত্র, শুধু nanosecond-এর জায়গায় millisecond; CPU cache-এর হিসাব Cache performance পর্বের অংশ ৩-এ। প্রচলিত ভুল: miss-এর খরচ শুধু t_db ধরা — miss-এও আগে cache দেখতে হয়েছে। ধরা যাক t_c = ১ ms, t_db = ২০ ms, সেকেন্ডে ১০,০০০ পড়া, আর ডেটাবেস স্বস্তিতে সামলায় সেকেন্ডে ২,৫০০ query:

// Read path with a cache in front of a database. ASSUMED inputs: change them and run again.
const T_CACHE = 1;     // ms for one cache lookup (paid on every request, hit or miss)
const T_DB = 20;       // ms for one database query (paid only on a miss)
const RPS = 10000;     // read requests per second
const DB_CAP = 2500;   // queries per second the database serves comfortably
const col = (v, w) => String(v).padStart(w);

console.log(`no cache: every read costs ${T_DB} ms and the DB gets ${RPS} q/s`);
console.log(col("hit", 7) + col("avg ms", 8) + col("vs no cache", 13) + col("DB q/s", 8) + col("DB busy", 9));
for (const h of [0, 0.5, 0.75, 0.9, 0.95, 0.99, 0.999]) {
  const avg = h * T_CACHE + (1 - h) * (T_CACHE + T_DB);  // = T_CACHE + (1 - h) * T_DB
  const dbq = RPS * (1 - h);                              // only misses reach the DB
  console.log(col((h * 100).toFixed(1) + "%", 7) + col(avg.toFixed(2), 8) +
    col((T_DB / avg).toFixed(2) + "x", 13) + col(dbq.toFixed(0), 8) +
    col((100 * dbq / DB_CAP).toFixed(1) + "%", 9) + (dbq > DB_CAP ? "  OVERLOADED" : ""));
}
const hMin = 1 - DB_CAP / RPS;
console.log(`\nDB keeps up only if hit ratio >= 1 - ${DB_CAP}/${RPS} = ${hMin.toFixed(2)}`);
console.log(`a miss still costs ${T_CACHE + T_DB} ms: with >1% misses, p99 is a miss`);

no cache: every read costs 20 ms and the DB gets 10000 q/s
    hit  avg ms  vs no cache  DB q/s  DB busy
   0.0%   21.00        0.95x   10000   400.0%  OVERLOADED
  50.0%   11.00        1.82x    5000   200.0%  OVERLOADED
  75.0%    6.00        3.33x    2500   100.0%
  90.0%    3.00        6.67x    1000    40.0%
  95.0%    2.00       10.00x     500    20.0%
  99.0%    1.20       16.67x     100     4.0%
  99.9%    1.02       19.61x      10     0.4%

DB keeps up only if hit ratio >= 1 - 2500/10000 = 0.75
a miss still costs 21 ms: with >1% misses, p99 is a miss

২ · কী cache করবেন, আর কী করবেন না

তিনটি প্রশ্ন দিয়ে শুরু করুন। বারবার পড়া হয় তো? — read:write অনুপাত যত বেশি, লাভ তত; একবার লিখে একবার পড়া জিনিস cache-এ শুধু memory খায়। আনতে বা বানাতে খরচ বেশি? — join, aggregation, অন্য সার্ভিসের ধীর API, রেন্ডার করা HTML. একটু পুরোনো হলে ক্ষতি কতটা? — cache-এর কপি সবসময় একটু পিছিয়ে থাকতে পারে; সেই staleness ব্যবসা সহ্য করে কি না, সেটিই শেষ কথা।

Session Redis-এ রাখা আসলে cache নয় — সেখানে সেটিই একমাত্র কপি। পর্ব ১৫-এ দেখেছেন, সেই store-এ eviction মানে হঠাৎ লগআউট। আর কতটুকু রাখবেন — চাহিদা Zipf-ধাঁচের হলে অল্প জিনিসেই বড় hit ratio মেলে (পর্ব ১৭-এর অংশ ৬)।

৩ · পড়ার কৌশল — cache-aside আর read-through

Cache-এ ডেটা কে আনবে আর কখন, আর লেখা হলে কপির কী হবে — এই দুই প্রশ্নের উত্তরই একেকটি caching কৌশল। ছবিতে চারটি প্রধান পথ একসাথে; নিচে একে একে।

Cache-aside (lazy loading)

Cache-aside-এ cache একটি নিষ্ক্রিয় তাক — সে ডেটাবেস চেনে না। সব কাজ app-এর: আগে cache দেখা, miss হলে নিজে ডেটাবেস থেকে পড়া, তারপর ফলটি একটি TTL দিয়ে cache-এ রেখে দেওয়া। “Lazy” কারণ কেউ না চাইলে কিছুই cache-এ ওঠে না। Redis বা Memcached-এর সাথে সবচেয়ে প্রচলিত কৌশল এটিই; Redis-এর কমান্ড-স্তরের উদাহরণ DBMS কোর্সের Redis পর্বের caching অংশে।

function getProduct(id):
    key = "product:" + id
    v = cache.get(key)                       # ১ আগে cache
    if v != null:
        return v                             # hit
    v = db.query("SELECT ... FROM products WHERE id = ?", id)   # ২-৩ miss: app নিজে DB-তে
    cache.set(key, v, ttl = 300)             # ৪ পরের জনের জন্য রেখে দেওয়া, ৩০০ সেকেন্ড
    return v

Read-through

Read-through-এ app শুধু cache-কে চেনে। Miss হলে cache বা cache-library নিজেই একটি loader ফাংশন চালিয়ে ডেটাবেস থেকে আনে, জমায়, তারপর উত্তর দেয়। Java-র JCache-এর CacheLoader বা Caffeine library-র LoadingCache এই ধাঁচের। সাধারণ Redis সার্ভার নিজে ডেটাবেস থেকে কিছু আনে না (কিছু module বা বাণিজ্যিক সংস্করণে এমন সুবিধা আছে), তাই Redis-এর সাথে read-through সাধারণত app-এর পাশের একটি library-স্তর। লাভ: logic এক জায়গায়, আর অনেক loader একই key-এর একসাথে আসা miss-কে একটিমাত্র load-এ মেলায় (documentation দেখে নিশ্চিত হোন)। দাম: cache-স্তরকে ডেটার উৎস আর গঠন জানতে হয়।

৪ · লেখার কৌশল — write-through, write-behind আর write-around

পড়ার কৌশল ঠিক করে cache কীভাবে ভরে; লেখার কৌশল ঠিক করে ডেটা বদলালে দুই কপি — cache আর ডেটাবেস — কীভাবে মেলে, আর কখন ব্যবহারকারীকে “OK” বলা হয়।

Write-through — দুই জায়গায় একসাথে

Write-through-এ প্রতিটি লেখা cache আর ডেটাবেস দুটোতেই যায়, আর দুটো শেষ হলে তবেই “OK”. লাভ: যে key লেখা হলো, তার কপি সাথে সাথে টাটকা — লেখার পরের প্রথম পড়াও hit. দাম: লেখার latency cache আর ডেটাবেস মিলিয়ে (একসাথে পাঠালেও ধীরটির সমান); আর এমন ডেটাও cache-এ ঢোকে যা হয়তো কেউ পড়বে না — লেখা-ভারী কাজে memory অপচয়, তাই এখানেও TTL লাগে। দুটি লেখা আসলে দুটি আলাদা কাজ: একটি সফল আরেকটি ব্যর্থ হলে কপি দুটি আলাদা। প্রচলিত ক্রম: আগে ডেটাবেস (সত্যের উৎস), তারপর cache, আর cache-এ ব্যর্থ হলে key মুছে দেওয়া। CPU-তেও একই নাম; সেখানে store-এর দেরি লুকাতে write buffer (Cache performance পর্বের অংশ ১)।

Write-behind (write-back) — আগে cache, পরে ডেটাবেস

Write-behind-এ লেখা যায় শুধু cache-এ, app সাথে সাথে “OK” পায়। Cache-এ বদলানো কিন্তু ডেটাবেসে না-লেখা entry — dirty entry — একটি পেছনের কাজ নির্দিষ্ট সময় পরপর batch-এ ডেটাবেসে লেখে, যাকে বলে flush. CPU আর OS-এর জগতে এর নাম write-back, caching library-তে প্রায়ই write-behind. লাভ তিনটি: লেখার latency প্রায় শুধু cache-এর; হঠাৎ লেখার ঢেউ cache শুষে নেয়; আর একই key-তে বারবার লেখা flush-এ এক হয়ে যায় — write coalescing. View বা like-এর মতো counter-এ এটি বিশাল সাশ্রয়।

দাম গুরুতর: flush-এর আগে cache node বিকল হলে যে লেখার জন্য ব্যবহারকারী “OK” পেয়েছেন, তা হারায় — durability-র প্রতিশ্রুতি ভাঙে। ধাপে ধাপে দেখুন:

Flush-এর ব্যবধান কত রাখবেন? নিচের simulator ১০ সেকেন্ডে ৫০টি key-তে ২,০০০টি লেখা চালায় (seeded PRNG, তাই প্রতিবার একই ফল), আর cache node মারা যায় ৭.৩৫ সেকেন্ডে:

// Write-through vs write-behind: 2000 counter updates on 50 keys over 10 s (seeded).
// ASSUMED: cache write 1 ms, DB write 20 ms, flush = one DB write per DIRTY key, done instantly.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const rnd = mulberry32(28), T_CACHE = 1, T_DB = 20, KEYS = 50, CRASH = 7350;   // crash at 7.35 s
const writes = Array.from({ length: 2000 }, () => ({ t: rnd() * 10000, key: Math.floor(rnd() * KEYS) }))
  .sort((a, b) => a.t - b.t);
const acked = writes.filter(w => w.t < CRASH);         // the app already said "OK" for these
console.log(`${acked.length} writes acknowledged before the cache node crashed at ${CRASH} ms\n`);
console.log("strategy            ms/write  DB writes  lost writes  keys hurt");
console.log("write-through".padEnd(20) + String(T_CACHE + T_DB).padStart(8) +
  String(acked.length).padStart(11) + "0".padStart(13) + "0".padStart(11));
for (const F of [100, 1000, 5000]) {                  // flush interval in ms
  const last = Math.floor(CRASH / F) * F;              // the last flush that finished
  let dbw = 0;
  for (let s = 0; s < last; s += F)                    // one DB write per dirty key per flush
    dbw += new Set(acked.filter(w => w.t >= s && w.t < s + F).map(w => w.key)).size;
  const lost = acked.filter(w => w.t >= last);         // only in the dead cache's memory
  console.log(`write-behind ${F} ms`.padEnd(20) + String(T_CACHE).padStart(8) + String(dbw).padStart(11) +
    String(lost.length).padStart(13) + String(new Set(lost.map(w => w.key)).size).padStart(11));
}

1479 writes acknowledged before the cache node crashed at 7350 ms

strategy            ms/write  DB writes  lost writes  keys hurt
write-through             21       1479            0          0
write-behind 100 ms        1       1213            7          7
write-behind 1000 ms       1        345           74         42
write-behind 5000 ms       1         50          472         50

হারানো ছাড়াও তিনটি সূক্ষ্ম ঝুঁকি। ক্রম: অর্ডার আর তার payment আলাদা key-তে; flush উল্টো ক্রমে বা আংশিক হলে ডেটাবেসে payment আছে, অর্ডার নেই। দেরিতে ধরা পড়া ভুল: unique শর্ত ভাঙলে তা ধরা পড়ে flush-এ, অথচ ব্যবহারকারী আগেই OK পেয়েছেন। অন্য পাঠক: report বা search সরাসরি ডেটাবেস পড়লে পিছিয়ে থাকা ছবি দেখে। প্রতিকার: cache-কে নিজেই টেকসই করা — replica আর append-only log (Redis-এর AOF প্রতি সেকেন্ডে fsync-এর সেটিংয়ে বিকলে মোটামুটি এক সেকেন্ডের লেখা হারাতে পারে; খুঁটিনাটি সংস্করণভেদে আলাদা) — বা আগে একটি টেকসই log-এ লেখা, অর্থাৎ write-ahead log-এর ধারণা (পর্ব ১৯; log-ভিত্তিক streaming পর্ব ৩৩-এ)। নিয়ম: টাকা, অর্ডার আর বুকিংয়ে write-behind নয়।

Write-around — শুধু ডেটাবেসে, cache এড়িয়ে

Write-around-এ লেখা সরাসরি ডেটাবেসে; cache-এ নতুন মান বসে না, বড়জোর পুরোনো key মুছে দেওয়া হয়। পরের পড়া miss হয়ে cache-aside-এর পথে নতুন মান আনে। লাভ: একবার লেখা আর কদাচিৎ পড়া ডেটা — log, পুরোনো অর্ডার, upload-এর তথ্য — cache দূষিত করে না। দাম: লেখার ঠিক পরের পড়া miss. বাস্তবে সবচেয়ে প্রচলিত জোড়া: পড়ায় cache-aside, লেখায় write-around আর delete.

৫ · Cache-aside-এর race — পুরোনো মান যখন চিরকাল থেকে যায়

Cache আর ডেটাবেস দুটি আলাদা সিস্টেম; দুটোকে একসাথে বদলানোর কোনো transaction নেই। তাই লেখার পথে দুটি আলাদা কাজ — ডেটাবেস বদলানো আর cache-এর কপি সামলানো — আর তাদের ক্রম, ব্যর্থতা আর অন্য অনুরোধের সাথে জড়িয়ে যাওয়াই সব সমস্যার উৎস। এ ধরনের ভুলের নাম race condition: একা চালালে কোড নির্ভুল, শুধু একটি দুর্ভাগা ক্রমে ভুল।

লেখার তিনটি ক্রম

• (ক) আগে cache delete, পরে ডেটাবেস — সবচেয়ে খারাপ। Delete আর COMMIT-এর মাঝখানে কোনো পাঠক এলে miss করবেন, ডেটাবেস থেকে পুরোনো মান পড়বেন (নতুনটি তখনো commit হয়নি) আর সেটিই cache-এ বসাবেন। জানালাটি পুরো লেখার সময়জুড়ে — ব্যস্ত key-তে প্রায় নিশ্চিত।
• (খ) আগে ডেটাবেস, পরে cache-এ নতুন মান — “update on write”. দুজন লেখক প্রায় একসাথে: B-র commit পরে, কিন্তু A-র set কোনো কারণে দেরিতে পৌঁছাল — cache-এ রইল A-র পুরোনো মান।
• (গ) আগে ডেটাবেসের COMMIT, পরে cache delete — প্রচলিত পথ। বাকি থাকে একটি race: পাঠক commit-এর আগে পুরোনো মান পড়েছেন, আর তাঁর set পৌঁছাল delete-এর পরে. একে বলে stale set.

কেন “update on write”-এর চেয়ে “delete on write” নিরাপদ

• Delete-এর ক্রম লাগে না, set-এর লাগে। দুটি delete যেকোনো ক্রমে পৌঁছাক, ফল একই — খালি key. দুটি set উল্টো ক্রমে পৌঁছালে পুরোনোটি জেতে।
• Retry নিরাপদ। Delete-এর timeout হলে আবার পাঠানো যায় — delete idempotent. দেরিতে আসা পুরোনো set-এর retry নতুন মানকে ঢেকে দিতে পারে।
• পড়া-বদলানো-লেখার ফাঁদ নেই। Update-এ অনেক app cache থেকে পুরো object এনে একটি field বদলে আবার set করে; দুজন দুটি আলাদা field বদলালে একজনের বদল হারায় — ডেটাবেসে দুটোই আছে, cache-এ একটি।
• অপচয় আর জটিলতা কম। একটি সারির বদল অনেক কপিতে পড়ে — পণ্যের পাতা, category-র তালিকা, cart. সবগুলোর নতুন মান লেখার পথে হিসাব করা ভারী আর ভুলপ্রবণ; মুছে দেওয়া সহজ।

তবে delete-ও race-মুক্ত নয়। নিচের simulator একটি ব্যস্ত key-তে তিন কৌশল পাশাপাশি চালায়: ৭০ ms-এর মধ্যে তিনটি লেখা, এক সেকেন্ডে ২০০টি পড়া, আর ধরা যাক ২% ধাপ হঠাৎ ৫০ থেকে ২০০ ms আটকে যায়। প্রতিটি কৌশল একই ২,০০০টি seed-এ — তাই তুলনা ন্যায্য, আর প্রতিবার একই ফল:

// Cache-aside on ONE hot key, many independent trials. Seeded: every run prints the same numbers.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const TRIALS = 2000, TTL = Infinity;     // TTL in ms (Infinity = never expires); try 200
const PAUSE = 0.02;                      // ASSUMED: 2% of steps stall 50-200 ms (GC, slow network)
function trial(mode, seed) {
  const rnd = mulberry32(seed), U = (lo, hi) => lo + rnd() * (hi - lo);
  const lag = (lo, hi) => rnd() < PAUSE ? U(50, 200) : U(lo, hi);
  const W = [0, 1, 2].map(() => U(0, 50) + U(5, 20));          // 3 writes commit by ~70 ms
  const WD = W.map(() => lag(0.5, 2));                          // commit -> cache step
  const R = Array.from({ length: 200 }, () => [U(0, 1000), lag(1, 5)]);  // read time, fill delay
  let db = 0, cache = null, gen = 0, stale = 0, late = 0; const ev = [];
  const at = (t, f) => { const i = ev.findIndex(e => e.t > t); ev.splice(i < 0 ? ev.length : i, 0, { t, f }); };
  W.forEach((t, k) => at(t, () => { const v = ++db;            // DB commit of version v
    at(t + WD[k], (t2) => { if (mode === "update") cache = { v, exp: t2 + TTL };  // set own value
                            else { cache = null; gen++; } }); })); // delete, which also voids leases
  for (const [t, d] of R) at(t, () => {
    if (t > 300) late++;                                        // all writes finished long before
    if (cache && cache.exp > t) { if (t > 300 && cache.v !== db) stale++; return; }   // hit
    const v = db, lease = gen;                                  // miss: read DB, take a lease
    at(t + d, (t2) => { if (mode === "lease" && lease !== gen) return;  // deleted meanwhile: refuse
                        cache = { v, exp: t2 + TTL }; });
  });
  while (ev.length) { const e = ev.shift(); e.f(e.t); }
  return [stale, late, cache && cache.v !== db ? 1 : 0];
}
console.log(`${TRIALS} keys, TTL = ${TTL} ms, stale = cache older than the DB`);
console.log("mode    stale keys at end   stale reads after t = 300 ms");
for (const mode of ["update", "delete", "lease"]) {
  let keys = 0, st = 0, all = 0;
  for (let s = 1; s <= TRIALS; s++) { const [a, b, c] = trial(mode, s); st += a; all += b; keys += c; }
  console.log(mode.padEnd(8) + String(keys).padStart(10) + String(st).padStart(17) +
    ` of ${all} (${(100 * st / all).toFixed(2)}%)`);
}

2000 keys, TTL = Infinity ms, stale = cache older than the DB
mode    stale keys at end   stale reads after t = 300 ms
update         183            25566 of 279473 (9.15%)
delete         240            33532 of 279473 (12.00%)
lease            0                0 of 279473 (0.00%)

প্রতিকার — ক্রম, TTL, lease, version আর log থেকে invalidation

1. ক্রম: ডেটাবেসের COMMIT-এর পরে delete — UPDATE বাক্যের পরে নয়। Transaction খোলা থাকলে অন্য পাঠক MVCC-তে তখনো পুরোনো মান দেখেন, তাই commit-এর আগের delete আসলে ক্রম (ক)।
2. TTL — নিরাপত্তা-জাল: race যত বিরলই হোক, প্রতিটি key-তে TTL থাকলে ভুল কপি বড়জোর TTL পর্যন্ত টেকে, চিরকাল নয়। TTL বাছুন ব্যবসা কতটা পুরোনো সহ্য করে তা দেখে; সব key-এর মেয়াদ একসাথে না ফুরাতে একটু এলোমেলো সময় যোগ করুন (পর্ব ২৯)।
3. Lease: Facebook-এর প্রকৌশলীদের “Scaling Memcache at Facebook” (NSDI ২০১৩) গবেষণাপত্রের বর্ণনা অনুযায়ী miss-এ memcache একটি token দেয়, সেই key-এ delete এলে token বাতিল, আর set চলে শুধু বৈধ token-এ — উপরের ধাপ ৭–৮. একই key-এ token কিছুক্ষণে একবারই দেওয়া হয়, বাকিরা একটু পরে আবার দেখেন — তাই lease thundering herd-ও কমায়।
4. Version-সহ মান: ডেটাবেসের সারিতে version কলাম (বা commit-এর ক্রমিক নম্বর), cache-এ মানের সাথে সেই version, আর set শুধু তখনই যখন নতুনটির version বড় — compare-and-set, Redis-এ সাধারণত ছোট একটি Lua script দিয়ে। ফাঁদ: key খালি থাকলে তুলনার কিছু নেই, পুরোনো set-ও সফল হবে। তাই delete-এর বদলে কিছুক্ষণ “version ৮ পর্যন্ত বাতিল” ধরনের একটি ছোট চিহ্ন রাখতে হয় — এক রকম tombstone.
5. Delayed double delete: commit-এর পরে delete, কয়েকশো ms পরে আবার delete — মাঝে বসা পুরোনো মান দ্বিতীয়টিতে মোছে। শিল্পে প্রচলিত কৌশল, কোনো মানসম্মত নিয়ম নয়: জানালা ছোট করে, বন্ধ করে না, আর প্রতিটি লেখায় বাড়তি miss আনে।
6. Log থেকে invalidation: app-এর বদলে একটি আলাদা প্রক্রিয়া ডেটাবেসের commit log পড়ে delete পাঠায় — change data capture. App commit-এর পরে crash করলেও delete হারায় না, আর delete আসে commit-এর ক্রমেই। পুরো ধারণা পর্ব ৩৩-এ।

# লেখা: আগে COMMIT, তারপর delete
function updatePrice(id, price):
    db.transaction:
        UPDATE products SET price = ?, version = version + 1 WHERE id = ?
    # COMMIT হয়ে গেছে — এবার, এর আগে নয়
    cache.delete("price:" + id)       # timeout হলে আবার; delete বারবার করা নিরাপদ

# পড়া: lease-সহ cache-aside
function getPrice(id):
    (v, token) = cache.get_or_lease("price:" + id)
    if v != null: return v
    if token == null:                 # অন্য কেউ এই key আনছেন
        sleep(5 ms); return getPrice(id)
    v = db.query("SELECT price FROM products WHERE id = ?", id)
    cache.set_if_lease("price:" + id, v, token, ttl = 300)   # মাঝে delete হলে প্রত্যাখ্যাত
    return v

৬ · নিজের লেখা নিজে দেখা — read-your-writes, replica আর cache

নাদিয়া প্রোফাইলে নিজের নাম বদলালেন, Save চাপলেন, পাতা reload — পুরোনো নাম! তিনি ভাববেন সেভ হয়নি, আবার চেষ্টা করবেন। এটি read-your-writes ভাঙা, যা পর্ব ২২-এর অংশ ৪-এ replica-র ক্ষেত্রে দেখেছেন। Cache এখানে সমস্যাটিকে বড় করে দুইভাবে।

• Replica থেকে fill: লেখা leader-এ commit হলো, delete-ও হলো; পরের miss-এ app পড়ল একটি read replica থেকে, যেখানে replication lag-এর কারণে বদল তখনো পৌঁছায়নি — পুরোনো নাম cache-এ বসল। Replica কয়েক ms-এ ঠিক হয়ে যায়, কিন্তু cache-এর ভুল কপি টেকে পুরো TTL.
• প্রতি সার্ভারের নিজস্ব cache: local cache-এ delete শুধু এক সার্ভারে হলে অন্যগুলোতে পুরোনো কপি; load balancer নাদিয়াকে কোন সার্ভারে পাঠায়, ফল তার ওপর নির্ভর করে।

প্রতিকার, সহজ থেকে কঠিন:

• লেখার পরে কিছুক্ষণ (replication lag-এর স্বাভাবিক সর্বোচ্চের চেয়ে বেশি) লেখকের পড়া leader থেকে, আর সেই ফল cache-এ না বসানো — session-এ “শেষ লেখার সময়” রেখে।
• লেখকের নিজের key-এ লেখার পথেই version-সহ নতুন মান বসানো — শুধু এই key-তে write-through.
• Invalidation আসুক replica-র নিজের log থেকে, অর্থাৎ বদল replica-তে পৌঁছানোর পরে delete (ভাবনার প্রশ্ন ২)।
• Local cache খুব ছোট TTL-এ, বা সব সার্ভারে ছড়ানো invalidation-সহ। বহু-স্তরের cache-এর নকশা পর্ব ৩০-এ।

৭ · আরও চারটি প্যাটার্ন — refresh-ahead, coalescing, negative caching আর আগে হিসাব করা ফল

Refresh-ahead — মেয়াদ ফুরানোর আগেই নবায়ন

শুধু TTL-এ চললে একটি জনপ্রিয় key-এর মেয়াদ ফুরানো মাত্র পরের অনুরোধগুলো miss — ব্যবহারকারী অপেক্ষা করেন, ডেটাবেস হঠাৎ ঝাঁক পায়। Refresh-ahead: মেয়াদের শেষ অংশে (ধরা যাক শেষ ২০%) কোনো অনুরোধ এলে তাঁকে বর্তমান কপিই দেওয়া হয়, আর পেছনে একটিমাত্র reload শুরু হয়; নতুন মান আসে মেয়াদ ফুরানোর আগেই। Caffeine library-র refreshAfterWrite এই ধাঁচের (খুঁটিনাটি documentation-এ), আর HTTP-র stale-while-revalidate একই চিন্তা (পর্ব ১৭)। একটি hot key-এ তিন পদ্ধতি:

// One hot key: 1 request per ms (1000 req/s) for 5 minutes. ASSUMED: TTL 60 s, DB reload 50 ms.
const DUR = 300000, TTL = 60000, LOAD = 50, AHEAD = 0.2;  // refresh in the last 20% of the TTL
function run(mode) {
  let exp = -1, done = -1, dbq = 0, waited = 0, worst = 0;
  for (let t = 0; t < DUR; t++) {
    if (done >= 0 && t >= done) { exp = done + TTL; done = -1; }      // a reload has landed
    if (t < exp) {                                                     // hit: answer from cache
      if (mode === "refresh-ahead" && done < 0 && exp - t < AHEAD * TTL) { dbq++; done = t + LOAD; }
      continue;                                                        // (reload runs in background)
    }
    waited++;                                                          // miss: this user waits
    if (mode === "TTL only") { dbq++; if (done < 0) done = t + LOAD; } // every miss hits the DB
    else if (done < 0) { dbq++; done = t + LOAD; }                     // one reload, others wait
    worst = Math.max(worst, done - t);
  }
  return [dbq, waited, worst];
}
console.log("mode                 DB queries  users who waited  worst wait ms");
for (const mode of ["TTL only", "TTL + coalescing", "refresh-ahead"]) {
  const [q, w, x] = run(mode);
  console.log(mode.padEnd(20) + String(q).padStart(11) + String(w).padStart(18) + String(x).padStart(15));
}

mode                 DB queries  users who waited  worst wait ms
TTL only                    250               250             50
TTL + coalescing              5               250             50
refresh-ahead                 7                50             50

Request coalescing — একই key-এর জন্য একজনই যান

একই key-এ একসাথে বহু miss এলে সবাইকে ডেটাবেসে না পাঠিয়ে একজনকে পাঠানো, বাকিরা তাঁর ফলের অপেক্ষায় — Go-র singleflight বা read-through library-র ভেতরের ব্যবস্থা। এক process-এর ভেতরে এটি সহজ; বহু সার্ভারের মধ্যে লাগে lease বা ছোট একটি lock. ফল প্রকাশের নকশায় এর হিসাব পর্ব ৬-এ, cache stampede-এর গভীর আলোচনা পর্ব ২৯-এ।

Negative caching — “নেই” উত্তরও মনে রাখা

কেউ বারবার এমন পণ্য চাইছেন যা নেই — পুরোনো লিংক, ভুল ID, বা স্বয়ংক্রিয় script. প্রতিবার miss, প্রতিবার ডেটাবেস, আর কিছু না পাওয়ায় cache-এ বসানোর কিছু থাকে না। Negative caching: “নেই” উত্তরটিই ছোট TTL-এ রাখা, যেমন product:999999 → NOT_FOUND ৩০ সেকেন্ড। বিপদ: পণ্যটি এইমাত্র তৈরি হলে ৩০ সেকেন্ড সবাই “নেই” দেখবেন। প্রতিকার: negative entry-র TTL খুব ছোট, আর তৈরির পথে সেই key delete. বিপুল সংখ্যক অস্তিত্বহীন key-এর জন্য memory বাঁচাতে Bloom filter — পর্ব ৪৫-এ।

আগে হিসাব করা ফল — aggregate আর read model

Trending তালিকা, leaderboard, “এই সপ্তাহের সেরা বিক্রি” — হাজার হাজার সারির হিসাব। প্রতিটি miss-এ এই হিসাব চালালে miss-ই ডেটাবেস বসিয়ে দেবে। তাই উল্টো পথ: একটি পেছনের কাজ প্রতি মিনিটে হিসাব করে ফলটি cache-এ লিখে দেয় — cache-এর দিক থেকে write-through-ধাঁচের ধাক্কা — আর পাঠক কখনো হিসাব চালান না, বড়জোর শেষ জানা ফল পান। এটি এক ধরনের materialized view. Event থেকে আলাদা read model বানানোর পুরো নকশা পর্ব ৩৫-এ, আর news feed-এর আগে-তৈরি feed পর্ব ৫৬-এ।

৮ · কৌশল বাছাই আর cache মাপা

কোনো কৌশল সব ডেটার জন্য সেরা নয়; একই সিস্টেমে আলাদা ডেটা আলাদা কৌশলে চলে। দুটি প্রশ্ন সিদ্ধান্তের বেশিরভাগ ঠিক করে দেয়: পুরোনো মান দেখালে ক্ষতি কত, আর একটি লেখা হারালে ক্ষতি কত।

Cache মাপা — চারটি সংখ্যা, আর দুটি বাড়তি

• Hit ratio: মোট, আর key-এর ধরন (prefix) অনুযায়ী আলাদা — গড়ের ৯৫% লুকিয়ে রাখতে পারে যে একটি ধরন ৪০%-এ।
• Latency: hit আর miss-এর আলাদা histogram, p50 আর p99. Miss-এর p99 আসলে ডেটাবেসের স্বাস্থ্যের খবর।
• Memory: ব্যবহার, key-এর সংখ্যা, মানের গড় আকার। কয়েক MB-এর একটি key network আর latency দুটোই নষ্ট করে।
• Eviction rate: জায়গার অভাবে প্রতি সেকেন্ডে কত key সরানো হচ্ছে। এই eviction বাড়তে থাকা মানে cache working set-এর চেয়ে ছোট, hit ratio পড়বে (পর্ব ২৯)।

সাথে দুটি: cache-এর পেছনে ডেটাবেসের QPS — আসল উদ্দেশ্যের মাপ — আর staleness, অর্থাৎ নমুনা key-এ cache আর ডেটাবেস মিলিয়ে দেখা। Dashboard, alert আর SLO পর্ব ৫০-এ। আর মাঝে মাঝে একটি পরীক্ষা: staging-এ cache বন্ধ করলে ডেটাবেস কতক্ষণ টেকে?

৯ · AI-এর যুগে — caching-এর পরামর্শ যাচাই

“সাইট ধীর” বললে AI প্রায় সবসময় বলে “Redis যোগ করুন”। Cache প্রায়ই উত্তরের অংশ, কিন্তু caching-এর ভুল নিঃশব্দ: কোনো error নেই, শুধু পুরোনো দাম, হারানো like, বা cache restart-এ বসে যাওয়া ডেটাবেস। চেনা ভুলগুলো:

AI-এর caching-পরিকল্পনা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি ডেটার জন্য “পুরোনো দেখালে ক্ষতি” আর “লেখা হারালে ক্ষতি” লেখা আছে, আর কৌশল তার সাথে মেলে
• গড় latency আর ডেটাবেসের ভার নিজে হিসাব করেছি — h = শূন্য অর্থাৎ খালি cache-সহ
• লেখার পথে ক্রম COMMIT-এর পরে delete; প্রতিটি key-তে TTL; হট key-তে lease বা version
• Write-behind থাকলে ক্ষতির জানালা (flush-এর ব্যবধান) জানা, আর টাকা-অর্ডারে তা নেই
• Redis বা Memcached-এর প্রতিটি ডিফল্ট আর সীমা নিজের সংস্করণের documentation-এ মিলিয়েছি
• ছোট simulation বা load test চালিয়েছি, আর failure-mode review: cache নেই, cache ধীর, cache ভুল মান দিচ্ছে