Overload সামলানো — queueing, backpressure, load shedding আর graceful degradation

১ · Overload কী — সিস্টেম কেন ধীরে না নেমে হঠাৎ ভেঙে পড়ে

একটি ফোনে-অর্ডার-নেওয়া রেস্তোরাঁর রান্নাঘর ঘণ্টায় ৬০টি খাবার বানাতে পারে। ঈদের আগের রাতে ঘণ্টায় ৯০টি অর্ডার এলো। রান্নাঘর একটু ধীর হলো না — প্রতি ঘণ্টায় ৩০টি অর্ডার জমতে লাগল। অনেক ক্রেতা অপেক্ষা না করে অর্ডার বাতিল করলেন, কিন্তু স্লিপগুলো হুকে ঝুলেই রইল, আর বাবুর্চি সেগুলোও রাঁধছেন। খাবার তৈরি হচ্ছে, নেওয়ার কেউ নেই।

সফটওয়্যারে একে বলে overload: কাজ আসার হার λ সামর্থ্য μ-এর চেয়ে বেশি, অল্প সময়ের জন্য হলেও। ব্যস্ততা ρ = ০.৯ মানে কষ্টে হলেও সামলানো যাচ্ছে (পর্ব ৪: গড় response time তখন service time-এর দশ গুণ)। কিন্তু ρ > ১ হলে কোনো স্থির অবস্থাই নেই: লাইন শুধু বাড়ে।

নিচের ছবিটি এই পর্বের মূল ছবি: ক্ষমতা সেকেন্ডে প্রায় ১০০, ক্লায়েন্ট ১ সেকেন্ডে হাল ছাড়ে, আর চাপ ৫০ থেকে ২০০। সংখ্যাগুলো অংশ ২-এর simulator থেকে।

এই নিচে নামা ঢালের নাম congestion collapse. Overload কোনো একদিন হবেই; লক্ষ্য হলো ক্ষমতার পরে বক্ররেখা সমতল রাখা — বাড়তিরা ফেরত যাক, গৃহীতরা সময়মতো শেষ হোক।

কেন ধস — তিনটি ফিরতি চক্র

1. নষ্ট কাজ: অপেক্ষা ক্লায়েন্টের timeout ছাড়ায়; ক্লায়েন্ট চলে যায়, কিন্তু সার্ভার পুরোনো অনুরোধে সময় খরচ করতেই থাকে।
2. বাড়তি চেষ্টা: timeout হলে আবার চেষ্টা; একই চাহিদা কয়েক গুণ অনুরোধ হয়ে ফেরে — retry storm.
3. কাজের দাম বাড়ে: ভিড়ে garbage collection, thread-এর পালাবদল, lock-এর লাইন আর নতুন TLS সংযোগে μ নিজেই কমে। অপারেটিং সিস্টেমে এর চেনা রূপ thrashing (Operating Systems · thrashing আর working set).

নিচের stepper-এ চক্রটি দেখুন: ক্ষমতা সেকেন্ডে ১০০, timeout ১ সেকেন্ড, ব্যর্থ হলে সর্বোচ্চ ৩ বার retry.

২ · Queueing-এর চোখে overload — অসীম queue একটি bug

পর্ব ৪-এ M/M/1 আর Little-এর সূত্র দেখেছেন: ρ < ১ হলে গড় সময় W = S/(1 − ρ)। ρ > ১ হলে সূত্রটি আর খাটে না, কারণ কোনো স্থির গড়ই নেই। তখন সরল একটি হিসাব কাজে আসে।

অসীম বা খুব বড় queue তাই একটি bug. কারণগুলো: জমা অনুরোধ memory খায়, একসময় process crash করে আর সব কাজ একসাথে হারায়। FIFO-তে সবচেয়ে পুরোনো অনুরোধ আগে সেবা পায় — ঠিক যাদের ক্লায়েন্ট আগে চলে গেছে। চাপ কমলেও জমা সরে কেবল μ − λ দিয়ে: ৩,০০০টি জমা আর বাড়তি ক্ষমতা সেকেন্ডে ২০ হলে আড়াই মিনিট। আর কেউ ফেরত পায় না বলে ত্রুটির হার শূন্য দেখায়, alert বাজে দেরিতে।

Queue কত বড় হবে — memory নয়, সময় দিয়ে মাপুন

Queue-র কাজ ক্ষণিকের ভিড় শোষণ, overload জমানো নয়। Little-এর সূত্র থেকে: K ≈ μ × সর্বোচ্চ গ্রহণযোগ্য অপেক্ষা। ক্ষমতা ১০০ আর অপেক্ষা সর্বোচ্চ ০.৫ সেকেন্ড হলে K ≈ ৫০। এর বেশি জমা মানে নতুন অনুরোধ এমনিতেই সময়মতো শেষ হবে না, তাই এখনই জানানো ভালো।

এবার তিন নকশা পাশাপাশি চালান: ক্ষমতা ১০০ (গড় service ১০ ms, এলোমেলো), timeout ১ সেকেন্ড, প্রতিটি চাপে ৩০ সেকেন্ড, ৩০% অনুরোধ জরুরি। নকশা: (১) অসীম queue; (২) ভেতরে সর্বোচ্চ ৫০, তারপর সঙ্গে সঙ্গে 503; (৩) অগ্রাধিকার — সাধারণ অনুরোধ ভেতরে ২০টি থাকলেই ফেরত, জরুরি ৫০ পর্যন্ত।

// Overload: one server, capacity 100 req/s (mean service 10 ms), client timeout 1 s.
// Each load level runs 30 s from empty. 30% of requests are critical (e.g. payments).
function rng(seed) {                                   // mulberry32: seeded, repeatable
  return () => { seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const T = 30, TIMEOUT = 1, S = 0.010;
const LIMIT = {                   // most requests allowed inside the server: [critical, other]
  "unbounded queue": [Infinity, Infinity],
  "bounded queue, fail fast": [50, 50],
  "priority shedding": [50, 20] };
function run(policy, load) {
  const rand = rng(42), exp = (mean) => -Math.log(1 - rand()) * mean;
  const fin = [], lat = []; let head = 0, t = 0, free = 0, rej = 0, crit = 0, critOk = 0;
  while ((t += exp(1 / load)) < T) {
    const isCrit = rand() < 0.3; crit += isCrit;
    while (head < fin.length && fin[head] <= t) head++;              // who has left by now
    if (fin.length - head >= LIMIT[policy][isCrit ? 0 : 1]) { rej++; continue; } // 503 now
    free = Math.max(free, t) + exp(S); fin.push(free);                // FIFO: wait, then serve
    if (free - t <= TIMEOUT && free <= T) { lat.push(free - t); critOk += isCrit; } // in time
  }                                                       // (late answers = wasted work)
  lat.sort((a, b) => a - b);
  const p99 = lat.length ? lat[Math.ceil(0.99 * lat.length) - 1] * 1000 : 0;
  return [load, (lat.length / T).toFixed(1), p99.toFixed(0), rej,
          (100 * critOk / crit).toFixed(0) + "%", fin.length - head];
}
Object.keys(LIMIT).forEach((policy, k) => {
  console.log((k ? "\n" : "") + policy + "\nload  good/s  p99 ms  rejected  critical ok  queue at 30 s");
  for (const load of [50, 80, 100, 120, 150, 200]) {
    const r = run(policy, load), w = [4, 8, 8, 10, 13, 15];
    console.log(r.map((v, i) => String(v).padStart(w[i])).join(""));
  }
});

unbounded queue
load  good/s  p99 ms  rejected  critical ok  queue at 30 s
  50    51.2     105         0         100%              3
  80    80.7     231         0         100%              2
 100    99.4     852         0         100%             10
 120    20.2     996         0          16%            511
 150     7.8     992         0           4%           1372
 200     5.8     934         0           2%           2853

bounded queue, fail fast
load  good/s  p99 ms  rejected  critical ok  queue at 30 s
  50    51.2     105         0         100%              3
  80    80.7     231         0         100%              2
 100    97.3     568        16          99%             27
 120   101.9     644       429          87%             46
 150    95.1     683      1580          64%             50
 200    98.4     669      2956          50%             50

priority shedding
load  good/s  p99 ms  rejected  critical ok  queue at 30 s
  50    51.2     105         0         100%              3
  80    79.0     226        11         100%              1
 100    93.0     279       162         100%              4
 120    98.8     288       599          99%             19
 150    96.2     317      1524          99%             22
 200    99.4     304      2821         100%             20

৩ · Backpressure — “একটু থামুন” বার্তা উৎস পর্যন্ত পৌঁছানো

Bounded queue একটি সীমা টানে। কিন্তু queue ভরে গেলে উৎসকে কী বলা হবে? এখানেই backpressure: পেছনের ধীর অংশের চাপ উল্টো দিকে সামনে পৌঁছে দেওয়া, যাতে উৎস কম পাঠায় বা থেমে থাকে।

Backpressure-এর চেনা রূপ

Pull বনাম push: push-এ উৎস নিজের গতিতে পাঠায়, তাই গ্রাহককে সংকেত দিতে হয় (window, credit, request(n)). Pull-এ backpressure আপনাআপনি: ধীর গ্রাহক কম টানে, আর জমা থাকে মাঝের queue-তে, যা সীমিত বা disk-এ টেকসই হতে হবে (message queue, পর্ব ৩১)। Disk-এ জমা ইমেইল পাঠানোর মতো পেছনের কাজে চলে, স্ক্রিনের সামনে অপেক্ষারত ব্যবহারকারীর অনুরোধে নয়।

নিচের ছবিতে অনুরোধ নিচে নামে (নীল), backpressure-এর সংকেত ধাপে ধাপে ওপরে ওঠে (কমলা ড্যাশ)।

এবার সংখ্যায়: প্রতিটি অনুরোধে একটি database query, ২০টি worker; Little-এর সূত্রে ক্ষমতা = worker-সংখ্যা ÷ query-র সময়।

৪ · Load shedding — আগে, সস্তায় আর অগ্রাধিকার বুঝে ফেরানো

বাংলাদেশে “লোডশেডিং” সবার চেনা: বিদ্যুতের চাহিদা উৎপাদন ছাড়ালে কিছু এলাকার সংযোগ পালা করে বন্ধ রাখা হয়, যাতে পুরো গ্রিড বসে না যায়; হাসপাতালের মতো জরুরি লাইন সাধারণত সবার শেষে। সফটওয়্যারের load shedding হুবহু এই ভাবনা। চারটি নিয়ম: আগে — দামি কাজ শুরুর আগে, পারলে load balancer বা gateway-তে (পর্ব ১১); সস্তায় — অংশ ২-এর হিসাব মনে রেখে; স্পষ্ট করে — ঠিক কোড আর কখন আবার চেষ্টা; আর বুঝে-শুনে — অগ্রাধিকার আর খরচ দেখে।

কোন কোড — 429, না 503?

HTTP/1.1 503 Service Unavailable
Retry-After: 5
Content-Type: application/problem+json
Cache-Control: no-store

{
  "type": "https://api.shop.example/problems/overloaded",
  "title": "Service is temporarily overloaded",
  "status": 503,
  "detail": "Please retry after about 5 seconds."
}

Retry-After সেকেন্ডে বা তারিখ-সময়ে লেখা যায়; ভালো ক্লায়েন্ট এটি মানে আর একটু jitter যোগ করে। উত্তরটি ছোট আর আগে থেকে তৈরি রাখুন — ফেরানোর মুহূর্তে লম্বা log লেখাও খরচ।

অগ্রাধিকার দেখে ফেরানো

প্রতিটি অনুরোধের একটি criticality বা অগ্রাধিকারের শ্রেণি থাকে। একটি কাল্পনিক অনলাইন দোকানে:

শ্রেণিটি header-এ নিচের সার্ভিসেও যায়; নইলে জরুরি পেমেন্ট নিচে গিয়ে “অজানা” হয়ে আগে ফেরত যেতে পারে (priority inversion). জরুরিদের জন্য আলাদা queue-ও চাই, নইলে তারা C-র লম্বা লাইনের পেছনে দাঁড়ায়। নিচে ভিড়ের সময়ে সার্ভিসটি দেখুন; নিয়ম: ক্ষমতা যতক্ষণ থাকে, আগে A, তারপর B, তারপর C. ডানের সংখ্যা “সেবা পেল / এসেছে”, প্রতি সেকেন্ডে।

অনুরোধ নয়, খরচ গুনুন

ধরা যাক একটি প্রোফাইল দেখতে ২ ms CPU লাগে, ৫০০টি ফলসহ একটি search-এ ২০০ ms — একটি search = ১০০টি প্রোফাইল। তাই অনেক ব্যবস্থা অনুরোধের বদলে খরচের একক গোনে: endpoint আর parameter (যেমন page size) দেখে আগে আন্দাজ, পরে আসল খরচ মিলিয়ে নেওয়া। Overload-এ দামি আর কম জরুরি অনুরোধ আগে ফেরত যায়, আর প্রতি ক্লায়েন্টের আলাদা ভাগ থাকে — যে বেশি পাঠাচ্ছে, আগে তাকেই ফেরানো।

৫ · Queue-কে বুদ্ধিমান করা — CoDel, LIFO আর concurrency limit

“কতজন লাইনে” দেখে সিদ্ধান্ত নেওয়া সহজ, কিন্তু অসম্পূর্ণ। ১০০ জনের লাইন দ্রুত চললে কোনো সমস্যা নেই; ২০ জনের লাইনও সমস্যা, যদি কাউন্টার আটকে থাকে। তাই আধুনিক queue দেখে প্রতিটি অনুরোধ লাইনে কতক্ষণ ছিল — sojourn time.

ভালো queue আর খারাপ queue — CoDel-এর ভাবনা

Kathleen Nichols আর Van Jacobson ২০১২ সালে ACM Queue-তে “Controlling Queue Delay” প্রবন্ধে CoDel প্রস্তাব করেন। ভালো queue ক্ষণিকের ভিড় শুষে নিজেই খালি হয়; খারাপ queue সবসময় ভরা থেকে শুধু দেরি করায়। চেনার উপায়: একটি সময়-জানালা (interval) ধরে সবচেয়ে কম sojourn time-ও লক্ষ্যমাত্রার (target) ওপরে থাকলে লাইনটি স্থায়ী — তখন ফেলা শুরু। Network-এ প্রস্তাবিত মান মোটামুটি target ৫ ms, interval ১০০ ms; আসল CoDel ফেলার ফাঁক ধীরে কমায় (interval ÷ √count). পরে এটি RFC 8289 (২০১৮) হয়।

উল্টো ব্যবস্থা tail drop: queue ভরা থাকলে নতুনটি ফেলে দেওয়া, নইলে লাইনের শেষে রাখা। বড় buffer-এ এটি প্রায় কিছুই ফেলে না, কিন্তু সবাইকে দীর্ঘ লাইনে দাঁড় করায় — নেটওয়ার্কে এর নাম bufferbloat. নিচের simulator-এর CoDel-ধাঁচে অনুরোধ তোলার সময় অপেক্ষা ৫০ ms ছাড়ালে ঘড়ি চালু হয়; টানা ১০০ ms ওপরে থাকলে অনুরোধটি বিনা কাজে ফেরত যায়। এখানে প্রতিটি কাজে ১০ ms লাগে, তাই target-ও network-এর ৫ ms-এর চেয়ে বড় ধরা হয়েছে।

// One server, 10 ms per request (100 req/s). Arrivals: 80 req/s, plus a burst that
// makes it 200 req/s from t = 2 s to 5 s. Both queues may hold up to 300 requests.
function rng(seed) {                                   // mulberry32: seeded, repeatable
  return () => { seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const S = 0.010, LIMIT = 300, TARGET = 0.050, INTERVAL = 0.100, END = 12;
function run(codel) {
  const rand = rng(5), arr = [], wait = [], q = [], zeros = () => new Array(END).fill(0);
  for (let t = 0; t < END; ) { t += -Math.log(1 - rand()) / (t >= 2 && t < 5 ? 200 : 80); arr.push(t); }
  const drops = zeros(), delay = zeros(), served = zeros();
  let i = 0, now = 0, aboveSince = null;
  while (now < END) {
    while (i < arr.length && arr[i] <= now) {           // arrivals up to now join the queue
      if (q.length >= LIMIT) drops[Math.floor(arr[i])]++; else q.push(arr[i]); i++; }
    if (!q.length) { now = arr[i]; aboveSince = null; continue; }    // queue empty: idle
    const t = q.shift(), sojourn = now - t;               // oldest waiting request
    if (codel && sojourn > TARGET) {
      if (aboveSince === null) aboveSince = now;          // above target: start the clock
      else if (now - aboveSince >= INTERVAL) { drops[Math.floor(now)]++; continue; } // drop
    } else aboveSince = null;                             // under target again: reset
    wait.push(sojourn); delay[Math.floor(now)] += sojourn; served[Math.floor(now)]++; now += S;
  }
  wait.sort((a, b) => a - b);
  const p99 = 1000 * wait[Math.ceil(0.99 * wait.length) - 1], dropped = drops.reduce((a, b) => a + b);
  return { cell: (s) => (1000 * delay[s] / served[s]).toFixed(0) + " ms / " + drops[s],
    sum: `served ${wait.length}, dropped ${dropped}, p99 ${p99.toFixed(0)} ms, ` +
         `waited > 1 s: ${wait.filter((w) => w > 1).length}` };
}
const td = run(false), cd = run(true);
console.log("second   tail-drop: delay / drops   CoDel-like: delay / drops");
for (let s = 0; s < END; s++) console.log(String(s).padStart(4) + td.cell(s).padStart(22) + cd.cell(s).padStart(26));
console.log("tail-drop : " + td.sum + "\nCoDel-like: " + cd.sum);

second   tail-drop: delay / drops   CoDel-like: delay / drops
   0              8 ms / 0                  8 ms / 0
   1             15 ms / 0                 15 ms / 0
   2            291 ms / 0               74 ms / 110
   3            828 ms / 0               75 ms / 101
   4          1355 ms / 38                77 ms / 93
   5           1854 ms / 0                32 ms / 32
   6           2393 ms / 0                 34 ms / 3
   7           2881 ms / 0                 13 ms / 0
   8           2905 ms / 0                  8 ms / 0
   9           2808 ms / 0                 20 ms / 0
  10           2616 ms / 0                  7 ms / 0
  11           2395 ms / 0                 17 ms / 0
tail-drop : served 1161, dropped 38, p99 2997 ms, waited > 1 s: 821
CoDel-like: served 1029, dropped 339, p99 116 ms, waited > 1 s: 0

Overload-এ নতুনজন আগে — adaptive LIFO

Overload-এ FIFO-র লাইনের মাথার অনুরোধটি সবচেয়ে পুরোনো, তার ক্লায়েন্ট হয়তো চলে গেছে। কিছু ব্যবস্থা তাই লাইন জমলে সবচেয়ে নতুনটিকে আগে সেবা দেয়, আর স্বাভাবিক সময়ে আবার FIFO — adaptive LIFO. ২০১৫ সালে ACM Queue-তে প্রকাশিত Ben Maurer-এর “Fail at Scale” প্রবন্ধে Facebook-এর সার্ভারে এর ব্যবহারের বর্ণনা আছে, সাথে CoDel-ধাঁচের একটি queue timeout-এরও (খুঁটিনাটি প্রবন্ধের বর্ণনা অনুযায়ী)। দাম: পুরোনো অনুরোধ লম্বা সময় সেবা না-ও পেতে পারে, তাই সাথে মেয়াদ-বাদের নিয়ম থাকে। এটি কিছু ব্যবস্থার কৌশল, সবার নিয়ম নয়।

Admission control আর concurrency limit — দরজায় গোনা

Admission control মানে দরজায় সিদ্ধান্ত: নেব কি না। কী গুনব — সেকেন্ডে কতগুলো (rate), না এই মুহূর্তে ভেতরে কতগুলো (concurrency limit)? Little-এর সূত্র L = λW দেখায় কেন দ্বিতীয়টি প্রায়ই ভালো। সীমা ভেতরে ২০টি আর W = ০.১ সেকেন্ড হলে throughput পর্যন্ত ২০ ÷ ০.১ = ২০০; dependency ধীর হয়ে W = ০.৫ হলে একই সীমা নিজেই ৪০-এ নামে। একটি স্থির rate limit তখনও ২০০ ঢোকাত, আর ভেতরে জমত।

সীমা কত? Load test থেকে একটি সংখ্যা নেওয়া যায়, কিন্তু hardware আর dependency বদলায়, তাই অনেক ব্যবস্থা TCP-র মতো নিজে খোঁজে। AIMD-তে সব ঠিক থাকলে সীমা ধীরে বাড়ে, latency বা timeout বাড়লে অনুপাতে কমে; gradient পদ্ধতি সবচেয়ে কম দেখা latency-র সাথে এখনকারটা তুলনা করে। Netflix-এর open-source concurrency-limits লাইব্রেরি (প্রায় ২০১৮) এমন পদ্ধতি দেয়; কিছু proxy-তেও এ সুবিধা আছে (সংস্করণভেদে আলাদা)।

// Illustrative sketch only: AIMD limit on requests in flight.
let limit = 20, inFlight = 0;
const baselineMs = 40;                 // e.g. the usual latency seen when healthy

function tryAdmit() {
  if (inFlight >= limit) return false; // reject now: 503 + Retry-After
  inFlight++;
  return true;
}

function onFinish(latencyMs, ok) {
  inFlight--;
  if (!ok || latencyMs > 2 * baselineMs) {
    limit = Math.max(1, Math.floor(limit * 0.9)); // multiplicative decrease
  } else {
    limit += 1 / limit;                // additive: about +1 per "limit" successes
  }
}

শেষ স্তর ক্লায়েন্ট: দরজাও ফেরাতে ফেরাতে ক্লান্ত হলে ক্লায়েন্ট নিজেই কিছু অনুরোধ পাঠানোর আগে বাতিল করে — client-side adaptive throttling. Google-এর SRE বইয়ে (২০১৬) বর্ণিত সূত্রে ক্লায়েন্ট সাম্প্রতিক পাঠানো (requests) আর গৃহীত (accepts) গোনে, আর নতুন অনুরোধ নিজের কাছেই বাতিল করে max(0, (requests − K × accepts) ÷ (requests + 1)) সম্ভাবনায়, K = ২। ১,০০০টি পাঠানো আর ৩০০ গৃহীত হলে (১,০০০ − ৬০০) ÷ ১,০০১ ≈ ০.৪০ — প্রায় ৪০% পাঠানোই হয় না।

৬ · Timeout, deadline আর retry budget — retry storm থামানো

প্রতিটি দূরের call-এ timeout লাগে, নইলে একটি ধীর dependency সব thread আটকায়। তার ওপর পুরো অনুরোধের সময়-বাজেট (ধরা যাক ১ সেকেন্ড) নিচের প্রতিটি call-কে জানাতে হয় — deadline propagation (পর্ব ৯)। Overload-এ এর বড় সুবিধা: সার্ভার কাজ শুরুর আগে দেখে deadline পেরিয়েছে কি না; পেরোলে বিনা খরচে বাদ, আর অংশ ১-এর নষ্ট কাজ বন্ধ।

Retry কত গুণ চাপ বাড়ায় — হিসাব

Exponential backoff আর jitter-এর ভাবনা পর্ব ৬-এ, পূর্ণ algorithm পর্ব ৪৮-এ (Resilience pattern). এখানে প্রশ্ন একটাই: টানা overload-এ backoff কি মোট চাপ কমায়? Simulator-এ নতুন অনুরোধ সেকেন্ডে ৭০, timeout ১ সেকেন্ড, সর্বোচ্চ ৩ বার retry; ক্ষমতা ১০০, কিন্তু ৩০–৬০ সেকেন্ডে ৫০ (যেমন অর্ধেক সার্ভার বিকল)। “সেরে ওঠা” = ৬০ সেকেন্ডের পরে প্রথম যে ৫ সেকেন্ডের জানালায় অন্তত ৯৫% চেষ্টা সময়মতো সফল।

// Retry storm: 70 new requests/s, client timeout 1 s, at most 3 retries per request.
// FIFO server: 100 req/s, but only 50 req/s from t = 30 s to 60 s (a capacity dip).
function rng(seed) {                                   // mulberry32: seeded, repeatable
  return () => { seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const END = 240, TIMEOUT = 1, NEW = 70, cap = (t) => (t >= 30 && t < 60 ? 50 : 100);
function sim(backoff, budget, dropExpired) {
  const rand = rng(9), exp = (mean) => -Math.log(1 - rand()) * mean;
  const due = [], att = new Array(END).fill(0), ok = new Array(END).fill(0);
  const add = (t, n) => { if (t < END) (due[Math.floor(t * 1000)] ||= []).push([t, n]); };
  for (let t = exp(1 / NEW); t < END; t += exp(1 / NEW)) add(t, 1);   // new requests
  let free = 0, tokens = 10;
  for (let ms = 0; ms < END * 1000; ms++) for (const [t, n] of due[ms] || []) {
    if (n === 1) tokens = Math.min(10, tokens + 0.1);  // budget: retries <= 10% of new
    att[Math.floor(t)]++;
    const start = Math.max(free, t), expired = dropExpired && start - t > TIMEOUT;
    if (!expired) free = start + exp(1 / cap(start));      // expired: skipped at no cost
    if (!expired && free - t <= TIMEOUT) { ok[Math.floor(t)]++; continue; }
    if (n > 3 || (budget && tokens < 1)) continue;         // give up
    if (budget) tokens -= 1;
    add(t + TIMEOUT + (backoff ? rand() * 0.5 * 2 ** n : 0), n + 1);  // full jitter
  }
  const sum = (a, i, j) => a.slice(i, j).reduce((x, y) => x + y, 0);
  let rec = 60; while (rec < END - 5 && sum(ok, rec, rec + 5) < 0.95 * sum(att, rec, rec + 5)) rec++;
  const amp = (i, j) => { const r = sum(att, i, j) / (j - i); return r.toFixed(0) + " (" + (r / NEW).toFixed(2) + "x)"; };
  return [amp(30, 60), amp(120, 180), rec < END - 5 ? rec - 60 + " s" : "never (by 240 s)"];
}
console.log("client policy              load/s in dip  load/s 120-180 s  recovery after 60 s");
for (const [name, b, g, d] of [["immediate retry", 0, 0, 0], ["backoff + jitter", 1, 0, 0],
    ["backoff + jitter + budget", 1, 1, 0], ["  + server drops expired", 1, 1, 1]]) {
  const r = sim(b, g, d);
  console.log(name.padEnd(26) + r[0].padStart(14) + r[1].padStart(18) + "  " + r[2]);
}

client policy              load/s in dip  load/s 120-180 s  recovery after 60 s
immediate retry              230 (3.29x)       279 (3.99x)  never (by 240 s)
backoff + jitter             217 (3.10x)       279 (3.98x)  never (by 240 s)
backoff + jitter + budget     75 (1.07x)        70 (1.00x)  30 s
  + server drops expired      75 (1.07x)        70 (1.00x)  0 s

৭ · Graceful degradation আর brownout — কম দিয়ে হলেও চালু থাকা

ফেরত দেওয়া শেষ উপায় নয়; অনেক সময় ভালো উপায় হলো কম দেওয়া। পর্ব ৫-এ graceful degradation-এর ভূমিকা দেখেছেন: কম গুরুত্বের সুবিধা ছেড়ে মূল কাজ চালু রাখা। Overload-এ এর হাতিয়ারগুলো:

দুটি শর্ত: বিকল্পটি যেন সেই overloaded অংশের ওপর নির্ভর না করে, আর নিয়মিত পরীক্ষা হয় — যে fallback কখনো চলেনি, প্রয়োজনের দিনে সাধারণত সেটি কাজ করে না।

Brownout — বাতি নেভে না, ম্লান হয়

ভোল্টেজ কমলে বাতি ম্লান হয়, নেভে না — ইংরেজিতে brownout. ২০১৪ সালে Cristian Klein ও সহকর্মীরা ICSE সম্মেলনে software-এর জন্য একই ধারণা প্রস্তাব করেন: পাতার একটি ঐচ্ছিক অংশ (যেমন সুপারিশ) কত শতাংশ অনুরোধে যোগ হবে, তা একটি “dimmer” response time দেখে ঠিক করে — চাপ বাড়লে নামে, কমলে ওঠে। Brownout চালু-বন্ধের বদলে ধীরে সমন্বয় করে, আর হাতে বন্ধ করা feature flag-এর চেয়ে দ্রুত সাড়া দেয়। সংকেত হোক queue-তে অপেক্ষার সময় আর p99, শুধু CPU নয়; আর hysteresis রাখুন (৮৫%-এ বন্ধ, ৭০%-এর নিচে কিছুক্ষণ থাকলে চালু)।

৮ · Metastable failure, dependency সুরক্ষা আর “হাঁটু” খোঁজা

পর্ব ৬-এ দেখেছেন, Nathan Bronson ও সহকর্মীরা ২০২১ সালে HotOS কর্মশালায় “Metastable Failures in Distributed Systems” প্রবন্ধে এর নাম দেন। প্রবন্ধটি তিনটি অবস্থা আলাদা করে: stable — ছোট ধাক্কা নিজেই সামলায়; vulnerable — সব ঠিক দেখায়, কিন্তু একটি ধাক্কা (trigger) এলেই পড়ে যাবে, আর দক্ষতার জন্য অনেক সিস্টেম এই অবস্থাতেই চলে; metastable — ধাক্কা গেছে, তবু একটি টিকিয়ে রাখা প্রভাব (sustaining effect) চাপ ধরে রাখে।

সেই প্রভাব শুধু retry নয়। ঠান্ডা cache: সব অনুরোধ database-এ, database-এ timeout, আর cache ভরে শুধু সফল পড়ায়, তাই আর গরম হয় না (এর একটি অংশ cache stampede, পর্ব ২৯)। দামি ব্যর্থতার পথ: লম্বা stack trace, failover-এর খোঁজ, নতুন connection. আর হাজারো client-এর একসাথে ফেরা (reconnect storm, পর্ব ১০)।

অংশ ৬-এর simulator-এ এটিই দেখেছেন। সারানোর পথ: চাপ স্বাভাবিকের চেয়েও নিচে নামানো — জোরালো shedding, retry বন্ধ, মেয়াদোত্তীর্ণ কাজ বাদ — তারপর traffic ধাপে ধাপে ফেরানো। প্রতিরোধে headroom রাখুন, আর নকশার সময়েই প্রশ্ন করুন: কোন প্রভাব ব্যর্থতাকে নিজেই টিকিয়ে রাখতে পারে?

Dependency সুরক্ষা — bulkhead আর circuit breaker

একটি সার্ভিস একই ১০০ thread-এর pool থেকে payment (সেকেন্ডে ৫০টি call, ৪০ ms) আর recommendation (২০০টি, ৫০ ms) ডাকে। Little-এর সূত্রে ব্যস্ত thread ২ + ১০ = ১২। Recommendation ধীর হয়ে ৬০০ ms নিলে তার একারই দরকার ২০০ × ০.৬ = ১২০টি — pool-এর বেশি; সব thread আটকায়, আর মাত্র ২টি thread-এর payment-ও ব্যর্থ হয়।

প্রতিকার bulkhead: প্রতিটি dependency-র আলাদা pool (ধরা যাক recommendation ২০, payment ১০), তাই শুধু recommendation-এর ২০টি ভরে। সাথে circuit breaker: বারবার ব্যর্থ dependency-কে কিছুক্ষণ ডাকাই বন্ধ, সঙ্গে সঙ্গে বিকল্প উত্তর। দুটির পূর্ণ নকশা পর্ব ৪৮-এ।

Load test — বক্ররেখার “হাঁটু” খুঁজে রাখা

এই পর্বের প্রতিটি সীমার সংখ্যা আসে মাপা থেকে। পর্ব ৪-এর load test-এর নিয়মের সাথে overload-এর জন্য:

• Open loop-এ (উত্তরের অপেক্ষা না করে নির্দিষ্ট হারে পাঠিয়ে) চাপ ধাপে ধাপে বাড়িয়ে goodput, p99 আর ত্রুটি লিখুন; p99 যেখানে হঠাৎ খাড়া, সেটিই knee বা “হাঁটু” — নিরাপদ ক্ষমতা তার কিছুটা নিচে।
• ক্ষমতার দ্বিগুণ চাপে goodput সমতল থাকা চাই (ছবি ১৮.১-এর নীল রেখা); নেমে গেলে অংশ ১-এর কোনো চক্র লুকিয়ে আছে।
• ক্ষমতা অর্ধেক করে ৩০ সেকেন্ড পরে ফেরান — সিস্টেম ফেরে, নাকি আটকে থাকে?
• Dashboard-এ (পর্ব ৫০): queue-তে অপেক্ষার সময়, চলমান অনুরোধ, শ্রেণিভেদে ফেরত, retry-র অনুপাত, আর throughput-এর পাশে goodput.

৯ · AI-এর যুগে overload-এর নকশা যাচাই

“আমাদের API ভিড়ে বসে যায়, কী করব?” — AI প্রায়ই বলে “Kafka বসান, Redis-এ cache করুন, autoscaling আর microservice.” মূল প্রশ্নের উত্তর তাতে নেই: ক্ষমতা ছাড়ালে কাকে, কোথায়, কত সস্তায় ফেরাবেন? সাধারণ ভুলগুলো:

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

• Retry-সহ মোট চাপ আর ধস শুরুর সময় T* নিজে আবার হিসাব করেছি
• প্রতিটি queue-র একটি সীমা আছে, আর তা অপেক্ষার সময় থেকে ঠিক করা
• ফেরানো হয় দামি কাজের আগে, স্পষ্ট 503/429 আর Retry-After দিয়ে; জরুরি শ্রেণি আলাদা করে রক্ষিত
• Retry-তে budget, backoff আর jitter আছে, আর শুধু একটি স্তরে; deadline নিচের call-এ পৌঁছায়
• একটি simulation বা load test চালিয়েছি — ক্ষমতার দ্বিগুণ চাপে goodput সমতল থাকে, আর ধাক্কার পরে সিস্টেম ফেরে
• Failure-mode পর্যালোচনা করেছি: কোন dependency ধীর হলে কী আটকায়, আর কোন প্রভাব ব্যর্থতাকে টিকিয়ে রাখতে পারে