CDN আর edge — static ও dynamic content, origin shield আর edge computing

১ · CDN কেন — দূরত্ব, origin-এর ভার, bandwidth-এর খরচ আর হঠাৎ ভিড়

একটি কাল্পনিক অনলাইন সংবাদ-সাইট: পাঠকের বেশিরভাগ বাংলাদেশে, সার্ভার ইউরোপের একটি cloud region-এ। প্রতিটি পাতায় কয়েক ডজন ছবি, CSS আর JavaScript ফাইল, আর প্রতিটি অনুরোধ সমুদ্রের নিচের cable ধরে হাজার হাজার কিলোমিটার যায়-আসে। এমন দূরত্বে RTT আলোর গতির কারণেই কয়েকশো মিলিসেকেন্ডের কাছাকাছি — হিসাবটি পর্ব ৭-এর অংশ ৮-এ।

সমাধান: জনপ্রিয় জিনিসের কপি ব্যবহারকারীর কাছের শহরে। এমন সার্ভারের জাল CDN; প্রতিটি শহরের সার্ভার-গুচ্ছ একটি edge বা PoP (point of presence). Caching header আর CDN-এর ভেতরের কৌশল protocol ধরে শেখানো হয়েছে Computer Networks-এর Web cache, proxy আর CDN পর্বে। এখানে প্রশ্ন নকশাকারের: কী রাখব, কতক্ষণ, কোন নামে — আর তাতে origin, খরচ আর ব্যবহারকারীর কী লাভ বা ঝুঁকি।

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

পুরো কাঠামো নিচের ছবিতে: কাছের edge, না পেলে আঞ্চলিক shield, সেখানেও না পেলে তবেই origin.

২ · একটি অনুরোধের পথ — কাছের edge খোঁজা, miss, shield, origin, তারপর hit

কাছের edge-এ পৌঁছানোর দুই পথ, দুটোই পর্ব ৭-এ দেখেছেন। DNS দিয়ে: সাইটের নাম CNAME দিয়ে CDN-এর নামে যায়, আর CDN-এর DNS প্রশ্নকর্তার এলাকা দেখে কাছের edge-এর IP দেয় — GeoDNS-এর মতো। Anycast দিয়ে: সব edge একই IP ঘোষণা করে, routing নিজেই কাছেরটিতে পাঠায়। দুর্বলতা আর TTL-এর প্রভাব পর্ব ৭-এর অংশ ৩-এ, পুরো DNS-যাত্রা CN-এর CDN অংশে।

Edge-এ পৌঁছানোর পর কী হয়? ঢাকার একজন পাঠক চাইছেন /img/banner-42.webp; origin বলে Cache-Control: public, max-age=86400 — এক দিন। RTT ধরে নেওয়া, গোল করা; tier-গুলোর connection আগে থেকে খোলা।

শিক্ষা: CDN গড় দেরি কমায় hit দিয়ে; প্রথম বা কদাচিৎ চাওয়া অনুরোধ বরং সামান্য ধীর। গড় latency ≈ h × t_hit + (১ − h) × t_miss; h = ০.৯৫-এ ০.৯৫ × ১১ + ০.০৫ × ২৩০ ≈ ২২ ms. Origin-এর চাপের অঙ্ক অংশ ৫-এ।

৩ · CDN-এ কী রাখবেন — static asset, ছবি-ভিডিও, API-র উত্তর আর ব্যক্তিগত পাতা

প্রতিটি content-এর জন্য তিন প্রশ্ন: উত্তর কি সবার জন্য এক? কত দ্রুত বদলায়, পুরোনো দেখালে ক্ষতি কত? বদলালে পুরোনো কপি কীভাবে সরবে? উত্তর লেখা হয় Cache-Control header-এ; নির্দেশগুলোর অর্থ CN-এর freshness অংশে।

Static asset — নামে hash, এক বছরের মেয়াদ

Build-এর সময় বিষয়বস্তুর hash নামে বসে — app.3f9a2c.js; একে বলে fingerprinting. একটি নামের বিষয়বস্তু কখনো বদলায় না, তাই এক বছর রাখা নিরাপদ, আর immutable (RFC 8246) reload-এও যাচাই এড়ায়। এই cache busting-এর খুঁটিনাটি CN পর্বের অংশ ৬-এ; এখানে দেখি এর আসল লাভ — নিরাপদ deploy.

ছবি আর ভিডিও

ছবি সাধারণত সবচেয়ে বেশি byte খায়, তাই byte hit ratio-র বড় অংশ এখানে। প্রতিটি আকার (w=400, w=800) আর format (WebP, AVIF, JPEG) আলাদা কপি, তাই রূপ সীমিত রাখুন — যেকোনো width চাইতে দিলে key অসীম, hit ratio পড়ে, আর বাইরের কেউ origin-কে অগণিত resize করাতে পারে। ভিডিও আসে ছোট segment-এ; segment কখনো বদলায় না, বদলায় শুধু playlist. পুরো নকশা পর্ব ৫৯-এর case study-তে।

Cache করা যায় এমন API-র উত্তর

দামের তালিকা, স্কোর, পরীক্ষার ফল — সবার জন্য এক, কিন্তু বদলায়। নীতি: ছোট TTL, সাথে RFC 5861 (২০১০)-এর দুটি নির্দেশ:

• stale-while-revalidate=N: মেয়াদ ফুরানোর পরেও N সেকেন্ড পুরোনো কপি সাথে সাথে, আর পেছনে নতুন কপি আনা — কেউ origin-এর জন্য অপেক্ষা করেন না।
• stale-if-error=N: origin error দিলে বা অনুপলব্ধ হলে N সেকেন্ড পর্যন্ত পুরোনো কপিই — graceful degradation-এর সবচেয়ে সস্তা রূপ (পর্ব ১৮)।

s-maxage শুধু shared cache-এর মেয়াদ, তাই ব্রাউজারকে ছোট আর CDN-কে বড় মেয়াদ দেওয়া যায়। কোন CDN কোন নির্দেশ মানে, বা RFC 9213-এর CDN-Cache-Control-এর মতো আলাদা header সমর্থন করে কি না — সেবাভেদে আলাদা; documentation দেখে আর মেপে নিশ্চিত হোন। চার ধরনের উত্তরের header:

# ১. নামে hash-ওয়ালা JavaScript
GET /assets/app.3f9a2c.js
Cache-Control: public, max-age=31536000, immutable

# ২. HTML: ব্রাউজার প্রতিবার যাচাই করে (304 সস্তা), CDN-এ ৬০ সেকেন্ড
#    (no-cache দিলে মান অনুযায়ী CDN-ও প্রতিবার যাচাই করত)
GET /news/4821
Cache-Control: max-age=0, s-maxage=60
ETag: "a91f"

# ৩. সবার জন্য এক API
GET /api/v1/prices?category=rice
Cache-Control: public, max-age=10, s-maxage=30, stale-while-revalidate=30, stale-if-error=600

# ৪. ব্যক্তিগত তথ্য — কোনো shared cache-এ নয়
GET /api/v1/me/orders
Cache-Control: private, no-store

ব্যক্তিগত content — কেন সাধারণত cache হয় না

যে উত্তরে নাম, ব্যালান্স বা token আছে, তা shared cache-এ জমলে পরের জন অন্যের তথ্য দেখবেন (ভাবনার প্রশ্ন ২)। নিরাপদে রাখলেও লাভ প্রায় নেই: উত্তর cookie বা ব্যবহারকারীর ওপর নির্ভর করলে key-তে ব্যবহারকারী লাগে, আর এক লাখ ব্যবহারকারী মানে এক লাখ কপি, প্রতিটি হয়তো একবার চাওয়া। Vary: Cookie ঠিক এটাই করে — hit ratio প্রায় শূন্য।

সমাধান পাতা ভাগ করা: সবার জন্য এক কাঠামো CDN থেকে, আর ব্যক্তিগত অংশ — “স্বাগতম, রুমা”, cart-এর সংখ্যা — ছোট একটি private API call-এ, যা TLS আর WAF-এর জন্য CDN-এর ভেতর দিয়ে গেলেও cache হয় না। মাঝামাঝি পথ: ব্যক্তির বদলে দল ধরে রূপ — দেশ, ভাষা, mobile-desktop. Session আর token-এর নকশা পর্ব ১৫-এ।

৪ · Cache key-এর নকশা — query string, Vary, cookie আর tracking param-এর ফাঁদ

Cache কপি খোঁজে একটি key দিয়ে; ডিফল্টে সাধারণত scheme, host, path আর পুরো query string (CDN-ভেদে আলাদা)। নকশার নিয়ম এক বাক্যে:

দুই দিকেই ভুল হয়। বেশি রাখলে — যে অংশ উত্তর বদলায় না, তা-ও key-তে — একই উত্তরের অসংখ্য কপি, hit ratio পড়ে যায়, origin-এ চাপ বাড়ে। কম রাখলে — যে অংশ উত্তর বদলায় তা বাদ — একজনের জন্য বানানো উত্তর আরেকজন পান: ভুল ভাষা, ভুল দাম, কখনো অন্যের তথ্য। দ্বিতীয় ভুলের ইচ্ছাকৃত অপব্যবহারের নাম web cache poisoning; প্রতিরক্ষা CN পর্বের অংশ ৬-এ।

Query string normalization

একই খবরের লিংক আসে ?utm_source=fb, ?fbclid=… বা ?gclid=… নিয়ে। এগুলো marketing-এর হিসাব, উত্তর বদলায় না, অথচ key-তে থাকলে প্রতিটি লিংক আলাদা কপি — ভাইরাল খবরের দিনেই origin-এ সবচেয়ে বেশি চাপ। ক্রমও বিষয়: ?a=1&b=2 আর ?b=2&a=1 একই উত্তর, ভিন্ন key. প্রচলিত সমাধান, CDN-এর সেটিং বা edge function দিয়ে:

ALLOWED = { "/img/":  ["w", "fmt"],          # শুধু এই param উত্তর বদলায়
            "/api/v1/prices": ["category"],
            "/news/": [] }                    # খবরে কোনো param নয়

function cacheKey(req):
    host  = lowercase(req.host)
    path  = req.path                          # path বদলাবেন না, শুধু মানসম্মত
    keep  = ALLOWED[prefix(path)]             # allow-list: জানা param-ই রাখা
    q     = [(k, v) for (k, v) in req.query if k in keep]
    q     = sort(q by k)                      # ক্রম মানসম্মত
    if "w" in q: q["w"] = nearest(q["w"], [200, 400, 800, 1600])   # রূপ সীমিত
    enc   = "br" if "br" in req.acceptEncoding else ("gzip" if "gzip" in req.acceptEncoding else "id")
    return host + path + "?" + join(q) + "|" + enc   # cookie, User-Agent key-তে নেই

নিয়মটি allow-list: জানা param রাখা, অচেনা সব বাদ; উল্টো পথ (জানা tracking param বাদ) ভঙ্গুর, কারণ নতুন param আসতেই থাকে। ঝুঁকি: অ্যাপে উত্তর-বদলানো নতুন param (যেমন page=2) এল, কিন্তু তালিকায় উঠল না — সবাই প্রথম পাতাই পাবেন। তাই key-র নিয়ম কোডের মতো version, review আর test করুন।

Vary, cookie আর header

• Accept-Encoding: উত্তর gzip বা Brotli-তে চাপা, তাই key-তে লাগে — তবে কাঁচা মান হাজার রকম, কয়েকটিতে মানসম্মত করুন (উপরের enc).
• Vary: User-Agent এড়ান: প্রায় প্রতিটি অনুরোধ আলাদা key. দরকারে edge-এ ছোট শ্রেণি (mobile, desktop) বানিয়ে শুধু সেটি key-তে।
• Cookie key-তে নয়: static path-এ cookie উপেক্ষা আর Set-Cookie সরান; অনেক CDN Set-Cookie-যুক্ত উত্তর cache করেই না, ফলে একটি অপ্রয়োজনীয় cookie পুরো path-এর hit শূন্য করতে পারে।
• Negative caching: 404 অল্প সময় রাখলে অস্তিত্বহীন URL-এর বন্যা origin-এ যায় না; মেয়াদ বেশি হলে নতুন জিনিসও “নেই” দেখায় — তাই পর্ব ৬-এর ফল প্রকাশের নকশায় negative caching বন্ধ বা খুব ছোট রাখা হয়েছিল।

৫ · Hit ratio-র অঙ্ক — origin-এর ভার, egress আর origin shield

মোট অনুরোধ R প্রতি সেকেন্ডে, edge-এর hit ratio h. প্রতিটি অনুরোধ হয় hit, নয় miss; miss-এর অনুরোধগুলোই origin-এর দিকে যায়। তাই shield ছাড়া:

খেয়াল করুন origin দেখে miss ratio. h = ০.৯০ মানে miss ০.১০; h = ০.৯৯ মানে miss ০.০১. Hit ratio মাত্র ৯ শতাংশ-বিন্দু বাড়ল, অথচ origin-এর ভার কমল ১০ গুণ; ৯৯% থেকে ৯৯.৯% আবার ১০ গুণ। তাই hit ratio-কে “কয়টি নয়” দিয়ে ভাবা হয়, availability-র মতো (পর্ব ৫)। উল্টোটাও সত্য: ৯৯% থেকে ৯৮%-এ নামা শুনতে সামান্য, কিন্তু origin-এ চাপ দ্বিগুণ।

Shield-এর অঙ্ক — প্রতিটি edge স্বাধীনভাবে miss করলে

Edge E-টি, আর প্রত্যেকের নিজের cache. ধরুন একটি TTL-এর সময়-জানালায় প্রতিটি edge স্বাধীনভাবে একটি নির্দিষ্ট object-এর জন্য ওপরের স্তরে যেতে বাধ্য হয় p সম্ভাবনায় — সেখানে কেউ সেটি চেয়েছেন আর কপি নেই। তাহলে:

• Shield ছাড়া: জানালাপ্রতি origin-এ গড়ে E × p অনুরোধ (প্রতিটি edge আলাদা)।
• Shield থাকলে: shield প্রতি জানালায় object-টি একবারই আনে, যদি অন্তত একটি edge চায়; তার সম্ভাবনা ১ − (১ − p)^E. একই মুহূর্তে কয়েকটি edge-এর miss এলে shield সেগুলো এক করে একটিই অনুরোধ পাঠায় — request collapsing (coalescing).

দুই প্রান্ত। p = ১ — সব edge-এ জনপ্রিয়, যেমন হোমপেজের JS: গুণক ১/E, ৫০টি edge-এ ভার ৫০ গুণ কম। p খুব ছোট — long tail: (১ − p)^E ≈ ১ − E·p, তাই গুণক প্রায় ১; shield প্রায় কিছু বাঁচায় না, শুধু একটি বাড়তি hop. বাড়তি লাভ shield-এর বড় cache, যা edge থেকে সরে যাওয়া জিনিসও ধরে রাখে। একই অনুমানে হিসাব:

// Origin load behind a CDN. ASSUMED inputs: change them and run again.
const R = 100000;        // total requests per second arriving at the CDN
const SIZE_KB = 50;      // average response size, decimal KB (1 KB = 1000 bytes)
const EDGES = 50;        // edge locations, each with its own cache
const gbps = (rps) => rps * SIZE_KB * 1000 * 8 / 1e9;    // req/s -> Gbit/s
const col = (v, w) => String(v).padStart(w);

// Shield model: in one TTL window each edge, INDEPENDENTLY, needs a given object
// from upstream with probability p. No shield: the origin gets EDGES*p fetches.
// With a shield (one fetch per object per window): 1 - (1-p)^EDGES fetches.
const factor = (p) => (1 - Math.pow(1 - p, EDGES)) / (EDGES * p);

console.log(`users receive ${R} req/s = ${gbps(R).toFixed(1)} Gbit/s from the edges`);
console.log(col("edge hit", 8) + col("origin req/s", 14) + col("Gbit/s", 8) + " |" +
  col("shield p=1", 12) + col("p=0.1", 8) + col("p=0.02", 8));
for (const h of [0, 0.5, 0.9, 0.95, 0.99, 0.999]) {
  const o = R * (1 - h);                       // every edge miss goes upstream
  // h = 0 means nothing is cacheable, so a shield cannot help either
  const s = (p) => (h === 0 ? "-" : (o * factor(p)).toFixed(0));
  console.log(col((h * 100).toFixed(1) + "%", 8) + col(o.toFixed(0), 14) +
    col(gbps(o).toFixed(2), 8) + " |" + col(s(1), 12) + col(s(0.1), 8) + col(s(0.02), 8));
}
console.log("\n" + col("p", 6) + col("no shield", 12) + col("shield", 9) + col("factor", 9));
for (const p of [1, 0.5, 0.1, 0.02]) {
  const none = EDGES * p, sh = 1 - Math.pow(1 - p, EDGES);
  console.log(col(p, 6) + col(none.toFixed(1), 12) + col(sh.toFixed(3), 9) +
    col(factor(p).toFixed(3), 9));
}

users receive 100000 req/s = 40.0 Gbit/s from the edges
edge hit  origin req/s  Gbit/s |  shield p=1   p=0.1  p=0.02
    0.0%        100000   40.00 |           -       -       -
   50.0%         50000   20.00 |        1000    9948   31792
   90.0%         10000    4.00 |         200    1990    6358
   95.0%          5000    2.00 |         100     995    3179
   99.0%          1000    0.40 |          20     199     636
   99.9%           100    0.04 |           2      20      64

     p   no shield   shield   factor
     1        50.0    1.000    0.020
   0.5        25.0    1.000    0.040
   0.1         5.0    0.995    0.199
  0.02         1.0    0.636    0.636

এই সাজানোর নাম tiered caching; application-এর বহু-স্তরের cache পর্ব ৩০-এ।

৬ · Hit ratio কোথা থেকে আসে — Zipf জনপ্রিয়তা আর cache-এর আকার

ওয়েবের চাহিদা সমান ভাগে ছড়ানো নয়: অল্প কিছু জিনিস বারবার, বিপুল সংখ্যক জিনিস কদাচিৎ। প্রচলিত মডেল Zipf-ধাঁচের বণ্টন — জনপ্রিয়তার ক্রমে k-তম জিনিস চাওয়ার সম্ভাবনা ১/k^α-এর সমানুপাতিক। ১৯৯৯ সালে Breslau ও সহকর্মীদের একটি পরিচিত গবেষণায় web proxy-র trace-এ α মোটামুটি ০.৬ থেকে ০.৮-এর ঘরে পাওয়া গিয়েছিল; আপনার সাইটে মান আলাদা হবে, তাই নিজের log থেকে মাপুন। α যত ছোট, তত লম্বা long tail, আর cache দিয়ে hit ratio বাড়ানো তত কঠিন।

আদর্শ সীমা কত? ধরুন cache সবচেয়ে জনপ্রিয় k-টি জিনিস সবসময় ধরে রাখে। তখন hit ratio = প্রথম k-টির ওজন ÷ মোট ওজন। যোগফলকে integral দিয়ে আন্দাজ করলে, α ≠ ১ হলে:

α = ১-এ ফলটি চোখে পড়ার মতো: cache ১০ গুণ বড় করলে hit ratio বাড়ে একটি নির্দিষ্ট পরিমাণ (ln ১০ ÷ ln N), গুণ হারে নয়। N = ২০,০০০ হলে প্রতি ১০ গুণে মাত্র প্রায় ২৩ শতাংশ-বিন্দু। বাস্তবের cache সবচেয়ে জনপ্রিয়গুলো জানে না, সাম্প্রতিকতা দেখে আন্দাজ করে — যেমন LRU. LRU আর LFU-র তুলনা CN পর্বের অংশ ৮-এ, আর OS-এর page replacement-এ একই প্রশ্ন। নিচে একটি edge-এর LRU cache, ২০,০০০টি জিনিসের catalogue আর α = ০.৮; seeded PRNG বলে প্রতিবার একই ফল:

// One edge, LRU cache, Zipf-like popularity: object of rank k is requested with
// weight 1/k^ALPHA. Seeded PRNG (mulberry32), so every run prints the same numbers.
const N = 20000, ALPHA = 0.8, WARM = 20000, REQS = 200000;
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 cdf = new Float64Array(N); let sum = 0;
for (let k = 1; k <= N; k++) { sum += 1 / Math.pow(k, ALPHA); cdf[k - 1] = sum; }
function pick(u) {                      // binary search: first rank whose cdf >= u*sum
  let lo = 0, hi = N - 1; const x = u * sum;
  while (lo < hi) { const m = (lo + hi) >> 1; if (cdf[m] < x) lo = m + 1; else hi = m; }
  return lo + 1;
}
function lruHitRatio(cap) {
  const rnd = mulberry32(17), cache = new Map(); let hits = 0;
  for (let i = 0; i < WARM + REQS; i++) {
    const obj = pick(rnd());
    if (cache.has(obj)) { cache.delete(obj); cache.set(obj, 1); if (i >= WARM) hits++; }
    else { cache.set(obj, 1); if (cache.size > cap) cache.delete(cache.keys().next().value); }
  }
  return hits / REQS;
}
console.log(`catalogue ${N} objects, Zipf alpha ${ALPHA}, ${REQS} requests after ${WARM} warm-up`);
console.log("cache size  % of catalogue  LRU hit  top-k bound  origin share");
for (const cap of [20, 200, 1000, 2000, 6000]) {
  const lru = lruHitRatio(cap), bound = cdf[cap - 1] / sum;  // keep the cap most popular forever
  console.log(String(cap).padStart(10) + ((cap / N * 100).toFixed(1) + "%").padStart(16) +
    (lru * 100).toFixed(1).padStart(8) + "%" + (bound * 100).toFixed(1).padStart(12) + "%" +
    ((1 - lru) * 100).toFixed(1).padStart(13) + "%");
}

catalogue 20000 objects, Zipf alpha 0.8, 200000 requests after 20000 warm-up
cache size  % of catalogue  LRU hit  top-k bound  origin share
        20            0.1%     3.9%        14.8%         96.1%
       200            1.0%    17.4%        31.4%         82.6%
      1000            5.0%    34.6%        48.6%         65.4%
      2000           10.0%    44.9%        57.9%         55.1%
      6000           30.0%    66.7%        75.6%         33.3%

Hit ratio বাড়ানোর হাতল চারটি: cache বড় করা (shield-এর বড় cache), মেয়াদ বাড়ানো (অংশ ৭), key-র অপচয় কমানো (অংশ ৪), আর চাহিদা কম জায়গায় জড়ো করা — ৫০টির বদলে ১০টি বড় edge-এ প্রতিটি জিনিস বেশি বার দেখা হয়, তবে latency বাড়ে। আর hot set এক edge-এর memory-তে ধরলে সবচেয়ে সস্তা লাভ সেখানেই।

৭ · TTL, staleness আর purge — কতক্ষণ রাখবেন, কীভাবে ভোলাবেন

বড় TTL মানে বেশি hit আর কম origin-এর ভার, কিন্তু পুরোনো তথ্য দেখানোর ঝুঁকি — staleness. ছোট TTL উল্টো। ঠিক কতটা? ধরুন origin প্রতি P সেকেন্ডে উত্তরটি বদলায়, আর edge প্রতি T সেকেন্ডে নতুন কপি আনে (অনুরোধ ঘন ঘন এলে)। একটি অনুরোধের মুহূর্তে কপির বয়স a, যা ০ থেকে T-এর মধ্যে মোটামুটি সমভাবে ছড়ানো; আর a সময়ের মধ্যে একটি বদল ঘটে যাওয়ার সম্ভাবনা a/P (a ≤ P হলে)। গড় করলে:

T = P = ৬০ সেকেন্ডে প্রায় অর্ধেক উত্তর পুরোনো, আর পুরোনোগুলো গড়ে T/৩ সেকেন্ড পিছিয়ে; origin-এ edgeপ্রতি ঘণ্টায় প্রায় ৩৬০০ ÷ T অনুরোধ। নিচে সূত্রগুলোর যাচাই, সাথে SWR আর stale-if-error. উত্তরটি একটি দামের তালিকা, প্রতি ৬০ সেকেন্ডে বদলায়; edge-এ সেকেন্ডে ১০টি অনুরোধ; origin থেকে আনতে ০.৩ সেকেন্ড, তখন যারা আসে তারা সেই fetch-এর অপেক্ষায়। বদলের মুহূর্ত মিনিটের ১০টি ভিন্ন জায়গায় রেখে গড় করা, যাতে কাকতালীয় মিল ফল না বদলায়:

// One edge, one API response; the origin publishes a new version every 60 s. Requests: seeded
// Poisson, 10/s, one hour. An origin fetch takes 0.3 s; requests arriving meanwhile wait for it.
const RATE = 10, FETCH = 0.3, UPDATE = 60, HOUR = 3600;
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; }; }
function run(ttl, swr, sie, outage, off) {      // off = when, inside a minute, updates happen
  const rnd = mulberry32(42), up = (x) => !(outage && x >= 1800 && x < 1900); // 100 s outage
  let t = 0, have = false, ver = 0, at = 0, pend = -1, pv = 0, s = [0, 0, 0, 0, 0, 0];
  for (;;) {                                    // s = requests, fetches, stale, lag, waited, errors
    t += -Math.log(1 - rnd()) / RATE; if (t >= HOUR) break; s[0]++;
    if (pend >= 0 && t >= pend) { have = true; ver = pv; at = pend; pend = -1; }
    const cur = Math.floor((t + off) / UPDATE), age = have ? t - at : Infinity; let served = ver;
    if (age >= ttl) {                           // copy expired, or no copy yet
      if (pend < 0 && up(t)) { pend = t + FETCH; pv = cur; s[1]++; }
      if (age < ttl + swr || (!up(t) && age < ttl + sie)) served = ver;   // stale, no wait
      else if (pend >= 0) { s[4]++; served = pv; }                        // wait for fetch
      else { s[5]++; continue; }                                          // error
    }
    if (served < cur) { s[2]++; s[3] += t + off - UPDATE * (served + 1); }
  }
  return s;
}
function show(name, ttl, swr = 0, sie = 0, outage = false) {   // average over 10 phases
  const a = [0, 0, 0, 0, 0, 0];
  for (let off = 0; off < 60; off += 6) run(ttl, swr, sie, outage, off).forEach((v, i) => a[i] += v / 10);
  console.log(name.padEnd(22) + a[1].toFixed(0).padStart(8) + (a[1] * 50).toFixed(0).padStart(10) +
    ((a[2] / a[0] * 100).toFixed(1) + "%").padStart(7) + ((a[3] / a[2]).toFixed(1) + " s").padStart(8) +
    a[4].toFixed(0).padStart(8) + a[5].toFixed(0).padStart(7));
}
console.log("policy                origin/h x50 edges  stale avg lag  waited errors");
for (const ttl of [5, 30, 60, 300]) show(`max-age=${ttl}`, ttl);
show("30 + swr 30", 30, 30);
console.log("-- origin down from t=1800 s to t=1900 s --");
show("30 + swr 30", 30, 30, 0, true);
show("30 + swr 30 + sie 600", 30, 30, 600, true);

policy                origin/h x50 edges  stale avg lag  waited errors
max-age=5                  668     33400   4.5%   1.8 s    2647      0
max-age=30                 119      5950  25.1%  10.1 s     474      0
max-age=60                  60      3000  49.9%  20.0 s     263      0
max-age=300                 12       600  89.7% 135.4 s      51      0
30 + swr 30                119      5950  25.7%  10.2 s       3      0
-- origin down from t=1800 s to t=1900 s --
30 + swr 30                116      5800  25.9%  10.6 s       9    479
30 + swr 30 + sie 600      116      5800  27.2%  12.8 s       9      0

TTL বেছে নেওয়ার নিয়ম

1. আগে ব্যবসার প্রশ্ন: পুরোনো তথ্য কতক্ষণ চলে? হোমপেজে এক মিনিট, দামে হয়তো ৩০ সেকেন্ড, টাকা পাঠানোর পর ব্যালান্সে শূন্য — সেটি cache-এ নয়।
2. তারপর অঙ্ক: সর্বোচ্চ পিছিয়ে থাকা ≈ TTL + SWR; গড় পুরোনো ভাগ T ÷ ২P; ঘন চাওয়া জিনিসে origin-এর ভার ঘণ্টায় ≈ edge-সংখ্যা × ৩৬০০ ÷ T, shield-সহ প্রায় ৩৬০০ ÷ T.
3. বদলের খবর জানা থাকলে: দীর্ঘ TTL আর বদলের মুহূর্তে purge — staleness প্রায় শূন্য, ভারও কম; TTL তখন শুধু নিরাপত্তা-জাল।

Purge — URL ধরে, না tag ধরে

Purge মানে মেয়াদ শেষের আগেই CDN-কে কপিটি ভুলে যেতে বলা। URL ধরে purge সরল, কিন্তু একটি শিরোনাম থাকে খবরের পাতা, হোমপেজ, বিভাগ, API আর RSS-এ — সব URL অ্যাপের জানা কঠিন। তাই অনেক CDN দেয় surrogate key বা cache tag: origin প্রতিটি উত্তরে একটি header-এ লেখে সেটি কোন জিনিসের ওপর নির্ভর করে, আর পরে একটি tag ধরে সব মেলানো কপি একসাথে purge. Header-এর নাম, সীমা আর ছড়ানোর সময় CDN-ভেদে আলাদা।

সম্পাদনায় purge চলে, কিন্তু খুব ঘন ঘন বদলানো জিনিসে (লাইভ স্কোর) ছোট TTL আর SWR সহজ ও সস্তা। Invalidation-এর সাধারণ কৌশল পর্ব ২৮ আর ২৯-এ।

৮ · Cache-এর বাইরে edge — push বনাম pull, dynamic acceleration, edge computing, নিরাপত্তা, multi-CDN আর খরচ

Push বনাম pull CDN

বাস্তবে সীমারেখা ঝাপসা: pull CDN-এর origin প্রায়ই object storage, যেখানে আপনি ফাইল “push” করেন; আর জানা ভিড়ের আগে জনপ্রিয় URL একবার করে চেয়ে cache ভরা যায় — cache warming (পর্ব ৬)।

Dynamic acceleration — cache না হলেও CDN কেন দ্রুত

ব্যক্তিগত API বা checkout-এর উত্তর cache হয় না, তবু CDN-এর ভেতর দিয়ে প্রায়ই দ্রুত — dynamic acceleration. কারণ: handshake শেষ হয় কাছের edge-এ (TLS termination); edge থেকে origin-এ আগে খোলা, গরম connection (keep-alive, slow start পেরোনো); আর কিছু CDN নিজের network-এ পথ বাছে (লাভ পথভেদে আলাদা)। পর্ব ৭-এর নিয়মে নতুন HTTPS-এ প্রথম byte পর্যন্ত ৩ RTT; ধরা যাক ব্যবহারকারী ↔ origin RTT ২০০ ms, ব্যবহারকারী ↔ edge ১০ ms, edge ↔ origin ২০০ ms, origin-এর কাজ ৩০ ms:

• সরাসরি origin-এ: ৩ × ২০০ + ৩০ = ৬৩০ ms.
• Edge দিয়ে: handshake ২ × ১০ = ২০, তারপর অনুরোধ ১০ + edge থেকে গরম connection-এ ২০০ + কাজ ৩০ = ২৪০; মোট ২৬০ ms — cache ছাড়াই ৩৭০ ms কম।
• একই connection-এ পরের অনুরোধ: সরাসরি ২০০ + ৩০ = ২৩০ ms, edge দিয়ে ১০ + ২০০ + ৩০ = ২৪০ ms — এখানে edge বরং ১০ ms বাড়ায়। লাভ handshake-এ, প্রতিটি অনুরোধে নয়।

Edge computing — edge-এ ছোট প্রোগ্রাম

অনেক CDN edge-এ আপনার ছোট কোড চালাতে দেয় — নাম সেবাভেদে আলাদা, যেমন edge function বা worker; ধারণাটির নাম edge computing. ভালো কাজগুলোর মিল একটাই: সিদ্ধান্তের তথ্য অনুরোধের ভেতরেই আছে।

• Redirect আর rewrite: পুরোনো URL থেকে নতুনে, ভাষা বা দেশ দেখে সঠিক পাতায়; URL shortener-এর redirect-ও (পর্ব ৫৪)।
• A/B পরীক্ষা: ব্যবহারকারীর id-র hash দেখে দল বাছা, আর দলটি cache key-তে — দলপ্রতি একটি কপি, প্রতিজনের নয়।
• প্রাথমিক auth যাচাই: JWT-এর মতো স্বাক্ষর-করা token edge-এ যাচাই করে জাল বা মেয়াদোত্তীর্ণ অনুরোধ সেখানেই ফেরানো; চূড়ান্ত অনুমতি origin-এ (পর্ব ৫২)।
• Header আর key: অংশ ৪-এর normalization, নিরাপত্তা-header, অপ্রয়োজনীয় cookie সরানো।

সীমা (CDN আর plan-ভেদে আলাদা, লেখার সময়ের documentation দেখুন): অনুরোধপ্রতি CPU-সময় খুব কম, প্রায়ই মিলিসেকেন্ডের ঘরে; memory আর library সীমিত; আর সবচেয়ে বড় কথা — ডেটাবেস দূরে. প্রতিটি query দূরের region-এ একটি পূর্ণ round trip, তাই পরপর কয়েকটি query-তে edge উল্টো ধীর (ভাবনার প্রশ্ন ৪)। Edge-এর key-value store দ্রুত পড়া যায়, কিন্তু লেখা ছড়াতে সময় নেয় — eventual consistency (পর্ব ৪০); টাকা বা stock-এর কাজ তাই region-এ।

Edge-এ নিরাপত্তা — প্রতিরক্ষার প্রথম দেয়াল

সব traffic edge পেরিয়ে আসে, তাই প্রতিরক্ষার অনেকটা সেখানে বসানো সহজ:

• DDoS শোষণ: বন্যা-traffic anycast-এ বহু শহরে ভাগ হয়, network-স্তরের বন্যা edge-এই ছাঁকা হয়। পূর্ণ ছবি CN-এর DDoS-এর প্রতিরক্ষা অংশে।
• WAF আর rate limit: পরিচিত ক্ষতিকর ধরন আর অতিরিক্ত অনুরোধ edge-এ থামে। WAF নিরাপদ কোডের বিকল্প নয়; rate limit-এর algorithm পর্ব ৪৯-এ।
• TLS: আধুনিক version আর certificate-এর নবায়ন এক জায়গায়; edge থেকে origin-এর পথও এনক্রিপ্ট রাখুন।
• Origin আড়াল করা: origin-এর ঠিকানা জানলে কেউ CDN এড়িয়ে সরাসরি যেতে পারে। তাই origin শুধু CDN-এর অনুরোধ নেবে — ঠিকানা-তালিকা, গোপন header বা পারস্পরিক certificate যাচাই দিয়ে — আর তার IP প্রকাশ্য থাকবে না।

Authentication, secrets আর এনক্রিপশনের পুরো নকশা পর্ব ৫২-এ।

Multi-CDN — দুই CDN, দুই গুণ নিশ্চিন্ত?

একটি CDN-এর বিভ্রাট পুরো সাইটের বিভ্রাট। তাই বড় সেবা কখনো দুই বা বেশি CDN রাখে — multi-CDN: DNS বা steering সেবা দিয়ে ভাগ, অঞ্চলভেদে দ্রুতটি, বিকল হলে অন্যটি; সিদ্ধান্তে প্রায়ই আসল ব্যবহারকারীর মাপজোখ (RUM). দাম: দুটি cache আলাদা গরম হয়, তাই long tail-এ miss বাড়ে; শুধু সাধারণ সুবিধাগুলো ব্যবহার করা যায়; config, purge আর certificate দুই জায়গায় মেলাতে হয়; আর DNS দিয়ে সরানো DNS TTL-এ বাঁধা (পর্ব ৭)। সিদ্ধান্তটি availability আর খরচের তুলনা — সবার দরকার নেই।

খরচের মডেল

দাম প্রদানকারী, অঞ্চল আর চুক্তিভেদে আলাদা আর বদলায়, তাই এখানে সংখ্যা নয়, শুধু কাঠামো: CDN থেকে ব্যবহারকারীর দিকে প্রতি GB (অঞ্চলভেদে হার আলাদা), কখনো অনুরোধের সংখ্যা ধরে, আর edge function বা WAF-এর মতো সুবিধার আলাদা দাম। অন্য দিকে origin-এর cloud থেকে বেরোনো byte-এর egress — কিছু প্রদানকারী নিজেদের CDN-এ যাওয়া byte-এ ছাড় দেয়, যাচাই করুন।

Byte hit ৯০% থেকে ৯৯% হলে origin-এর egress ১০ গুণ কমে, কিন্তু CDN-এর বিল প্রায় একই — ব্যবহারকারী একই byte পান। সেই বিল কমায় ছোট ছবি আর ভালো compression. Bandwidth আর egress-এর হিসাব পর্ব ৩-এ।

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

“সাইট ধীর, ভিড় সামলাতে পারছে না” — AI প্রায়ই বলে “CDN বসান, সব cache করুন, Redis আর Kafka যোগ করুন”। CDN প্রায়ই উত্তরের অংশ, কিন্তু caching-এর ভুল নিঃশব্দ: একজনের তথ্য আরেকজন দেখেন, বা সংশোধন এক দিন পৌঁছায় না। চেনা ভুল:

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

• প্রতিটি path-এ “উত্তর কি সবার জন্য এক?” লেখা, ব্যক্তিগত path-এ private বা no-store
• Origin-এর ভার R × (১ − h) আর egress নিজে হিসাব করেছি, peak আর CDN-বিহীন অবস্থা দুটোই
• Cache key-তে কী আছে তা লেখা: tracking param বাদ, cookie বাদ, দরকারি param allow-list-এ
• TTL ব্যবসার staleness-সীমা থেকে বেছেছি, আর T ÷ ২P দিয়ে পুরোনো উত্তরের ভাগ মিলিয়েছি
• Purge-এর ক্রম (লেখা দেখা যাওয়ার পরে), ব্রাউজারের max-age আর “সব purge”-এর ঝুঁকি ভেবেছি
• Header আর সীমা documentation-এ মিলিয়েছি, আর curl -I দিয়ে আসল উত্তরে Cache-Control, Age আর hit-miss header দেখেছি
• ছোট load test বা simulation চালিয়েছি, আর failure-mode review: CDN নেই, shield নেই, origin ধীর