Resilience pattern — timeout, retry, backoff, circuit breaker আর bulkhead

১ · ব্যর্থতা কীভাবে ছড়ায় — cascading failure আর “ধীর, কিন্তু জীবিত” dependency

একটি রেস্তোরাঁয় ১০ জন ওয়েটার। আজ মিষ্টির কাউন্টারের কারিগর অসুস্থ, প্রতিটি দইয়ে ১০ মিনিট লাগছে, আর যে ওয়েটারই দইয়ের অর্ডার নেন, কাউন্টারে দাঁড়িয়ে থাকেন। আধা ঘণ্টায় ১০ জনই দইয়ের লাইনে; এক কাপ চায়ের অর্ডার নেওয়ারও কেউ নেই। দই না থাকলে ক্ষতি সামান্য ছিল; দই ধীর বলেই পুরো রেস্তোরাঁ থামল।

সফটওয়্যারে ওয়েটারের জায়গায় thread, connection বা memory — সীমিত সম্পদ। অন্য সার্ভিসকে (dependency) ডেকে অপেক্ষার সময় একটি thread আটকে থাকে। কতগুলো, তা বলে পর্ব ৪-এর Little-এর সূত্র:

সেকেন্ডে ৪০০টি call, প্রতিটি ৫০ ms হলে ব্যস্ত মাত্র ২০টি thread. একই call ৩ সেকেন্ড নিলে দরকার ১,২০০টি। Pool-এ ২০০টি থাকলে কয়েক মুহূর্তে সব ভরে যায় — একে বলে resource exhaustion. তখন যে অনুরোধের ওই dependency লাগেই না, সেটিও thread পায় না।

নিচের stepper-এ একটি কাল্পনিক অনলাইন দোকানের শিকল দেখুন। Gateway সেকেন্ডে ২,০০০টি অনুরোধ নেয়; তার ১,০০০টি যায় অর্ডার সার্ভিস X-এ। X-এর ২০০টি thread; প্রতিটি অনুরোধে নিজের কাজ ২০ ms, আর ৪০০টি অনুরোধ (cart-এর পাতা) অফার সার্ভিস D-কে ডাকে। বাকি ৬০০টি (অর্ডারের অবস্থা দেখা) D-কে ডাকেই না।

Cascading failure-এর আরও দুটি চেনা পথ: একটি সার্ভার পড়লে তার ভার বাকিদের ঘাড়ে গিয়ে তাদেরও ফেলা (পর্ব ৫, ১৮), আর স্তরে স্তরে retry-র ঢেউ (অংশ ৩)। এই পর্বের সব pattern-এর লক্ষ্য একটাই — ঢাকার মোড়ে বিকল বাসের জটকে সেই মোড়েই আটকে রাখা, পুরো শহরে ছড়াতে না দেওয়া।

২ · Timeout আর deadline — কতক্ষণ অপেক্ষা, আর পুরো শিকলের সময়-বাজেট

প্রথম নিয়ম সবচেয়ে সরল, তবু সবচেয়ে বেশি ভাঙা হয়: network-এর ওপারে প্রতিটি call-এর একটি timeout চাই। অনেক HTTP client আর database driver-এর ডিফল্ট timeout খুব বড় বা অসীম (লাইব্রেরিভেদে আলাদা)।

দুই রকম timeout, এক রকম deadline

• Connect timeout: সংযোগ স্থাপনের সীমা; একই ডেটা সেন্টারে এটি ছোট রাখা যায়।
• Request timeout: উত্তরের সীমা; retry থাকলে প্রতিটি চেষ্টার আলাদা — per-try timeout.
• Deadline: “কতক্ষণ” নয়, “কখন পর্যন্ত”। অনুরোধ এলে একবার ঠিক হয়, তারপর প্রতিটি নিচের call জানে কত সময় বাকি — deadline propagation.

Timeout কত হবে — তিনটি সীমা

আরেকটি সাধারণ ভুল উল্টো timeout: gateway ২ সেকেন্ডে হাল ছাড়ে, অথচ নিচের সার্ভিস ৫ আর database ১০ সেকেন্ড অপেক্ষা করে — caller চলে যাওয়ার পরেও কাজ চলে। নিয়ম: শিকলে যত নিচে, timeout তত ছোট।

নিচের stepper-এ একটি পেমেন্টের শিকলে ১,০০০ ms-এর deadline কীভাবে ভাগ হয়, দেখুন। Payment সার্ভিস ব্যাংকের gateway-কে ডাকে, যা আজ প্রায় ২ সেকেন্ড নিচ্ছে।

gRPC-তে deadline প্রায় আপনাআপনি নিচে যায় — যেমন Go-তে একই context পরের call-এ পাঠালে (খুঁটিনাটি ভাষাভেদে আলাদা)। HTTP-তে সর্বজনীন মান নেই, তাই দলকে একটি header আর নিয়ম ঠিক করে নিতে হয়।

৩ · Retry — কোন ত্রুটিতে, কতবার, আর স্তরে স্তরে গুণফল

ব্যাংকের কাউন্টারে টোকেন ডাকার সময় আপনি পানি খেতে গিয়েছিলেন। ফিরে এসে আবার টোকেন নেওয়া যুক্তিসংগত — সমস্যাটি ক্ষণিকের। কিন্তু কর্মকর্তা যদি বলেন “এই হিসাবে টাকা নেই”, দশবার লাইনে দাঁড়ালেও উত্তর বদলাবে না। Retry-র প্রথম প্রশ্ন তাই: ত্রুটিটি কি নিজে থেকে সেরে যেতে পারে?

দ্বিতীয় শর্ত idempotency: একই অনুরোধ দুবার পৌঁছালেও ফল একবারের মতো। GET, PUT আর DELETE সাধারণত স্বভাবেই এমন; POST-এ client একটি idempotency key পাঠায় (পর্ব ৮), বার্তায় dedup store (পর্ব ৩৪)। এই শর্ত ছাড়া retry একটি নতুন bug.

স্তরে স্তরে retry — গুণফলের অঙ্ক

অ্যাপ → API → সার্ভিস → database. প্রতিটি caller নিচেরটিকে সর্বোচ্চ ৩ বার ডাকে (১টি চেষ্টা + ২টি retry). Database পুরো বিকল হলে সার্ভিস তাকে ৩ বার ডাকে; API সার্ভিসকে ৩ বার, তাই database-এ ৩ × ৩ = ৯; অ্যাপ API-কে ৩ বার, তাই ৩ × ৩ × ৩ = ২৭টি database-চেষ্টা, একটিমাত্র ব্যবহারকারী-অনুরোধে। সাধারণভাবে n স্তরে প্রতিটিতে k বার চেষ্টা মানে kⁿ. পর্ব ১৮-এ প্রতিটিতে ৪ বার চেষ্টায় একই হিসাব দাঁড়িয়েছিল ৬৪-এ। এর নাম retry amplification, আর এটি আসে ঠিক তখন, যখন সবচেয়ে নিচের অংশটি সবচেয়ে দুর্বল।

প্রতিকার দুটি। এক, একটি স্তরে retry — সাধারণত ব্যর্থতার সবচেয়ে কাছের স্তরে; বাকিরা দ্রুত ত্রুটি ওপরে পাঠায়। দুই, retry budget — প্রতিটি client বা স্তরে retry প্রথম-চেষ্টার একটি অনুপাতের (ধরা যাক ১০%) মধ্যে। Google-এর SRE বইয়ে (২০১৬) প্রতি client-এ প্রায় ১০% retry ratio-র বর্ণনা আছে; gRPC-র retry throttling আর কিছু cloud SDK-র retry quota একই ভাবনার token bucket (খুঁটিনাটি implementation-ভেদে আলাদা)। নিচে দুটি নীতি পাশাপাশি:

// Chain: app -> API -> service -> database. Each of the 3 callers makes up to 3 attempts
// (1 try + 2 retries) on the layer below. Only the database fails: each attempt with prob. p.
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 LAYERS = 3, TRIES = 3, USERS = 1000;
function run(p, budget) {
  const r = mulberry32(48);
  const tokens = Array(LAYERS).fill(10);   // budget: per layer, retries <= 10% of its first tries
  let dbAttempts = 0;
  function call(layer) {                   // returns true if the call to `layer` succeeded
    if (layer === LAYERS) { dbAttempts++; return r() >= p; }    // the database itself
    for (let attempt = 1; attempt <= TRIES; attempt++) {
      if (attempt === 1) tokens[layer] = Math.min(10, tokens[layer] + 0.1);
      else if (budget) { if (tokens[layer] < 1) return false; tokens[layer] -= 1; }
      if (call(layer + 1)) return true;
    }
    return false;
  }
  let ok = 0;
  for (let u = 0; u < USERS; u++) if (call(0)) ok++;
  return [dbAttempts, (dbAttempts / USERS).toFixed(2) + "x", (100 * ok / USERS).toFixed(1) + "%"];
}
console.log("p(db fails)   no budget: db calls  per user  users ok |  10% budget: db calls  per user  users ok");
for (const p of [0.01, 0.1, 0.5, 0.9, 1.0]) {
  const a = run(p, false), b = run(p, true);
  console.log(String(p).padEnd(12) + String(a[0]).padStart(20) + a[1].padStart(10) + a[2].padStart(10) +
    " |" + String(b[0]).padStart(21) + b[1].padStart(10) + b[2].padStart(10));
}

p(db fails)   no budget: db calls  per user  users ok |  10% budget: db calls  per user  users ok
0.01                        1013     1.01x    100.0% |                 1013     1.01x    100.0%
0.1                         1115     1.11x    100.0% |                 1115     1.11x    100.0%
0.5                         2022     2.02x    100.0% |                 1360     1.36x     66.8%
0.9                         9410     9.41x     94.5% |                 1361     1.36x     12.5%
1                          27000    27.00x      0.0% |                 1361     1.36x      0.0%

৪ · Exponential backoff আর jitter — full, equal আর decorrelated

এবার কখন। প্রতিবার অপেক্ষা বাড়ানো হয়, সাধারণত দ্বিগুণ করে: base × 2^k, সাথে একটি ঊর্ধ্বসীমা cap — এটিই exponential backoff. কিন্তু শুধু এটুকুতে একটি ফাঁদ থাকে।

একসাথে ব্যর্থ হওয়া ক্লায়েন্টরা একই নিয়মে অপেক্ষা করলে একসাথেই ফেরে — ঢেউয়ের মতো। এই ঢেউ ভাঙে অপেক্ষার সময়ে এলোমেলো অংশ, অর্থাৎ jitter. AWS Architecture Blog-এ Marc Brooker-এর ২০১৫ সালের “Exponential Backoff And Jitter” লেখাটি simulation দিয়ে তিনটি রূপ তুলনা করে কৌশলটিকে জনপ্রিয় করে (পর্ব ৬)। k-তম retry-র আগে অপেক্ষা (rand(a, b) = a থেকে b-এর মধ্যে এলোমেলো):

এবার সংখ্যায়। ১০০টি ক্লায়েন্ট t = ০-তে একটি ক্ষণিকের বিভ্রাটে একসাথে ত্রুটি পেল। তারপর থেকে সার্ভার সুস্থ, কিন্তু প্রতি ১০০ ms-এ মাত্র ২টি call নিতে পারে (সেকেন্ডে ২০); বাড়তিগুলো সাথে সাথে ফেরত যায় (পর্ব ১৮-এর fail fast), আর সেই ক্লায়েন্ট আবার backoff করে। base = ২০০ ms, cap = ১০ সেকেন্ড। তাত্ত্বিক সর্বনিম্ন: ১০০ ÷ ২০ = ৫ সেকেন্ড, ১০০টি call.

// 100 clients all get an error at t = 0 (a brief outage). From then on the server is up but
// accepts at most 2 calls per 100 ms slot (20/s); extra calls are rejected at once and back off.
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 BASE = 0.2, CAP = 10, CLIENTS = 100, PER_SLOT = 2, SLOT = 0.1;       // seconds
const WAIT = {                                  // delay before retry number k (k = 1, 2, ...)
  "no jitter":    (k, prev, r) => Math.min(CAP, BASE * 2 ** k),
  "full jitter":  (k, prev, r) => r() * Math.min(CAP, BASE * 2 ** k),
  "equal jitter": (k, prev, r) => { const t = Math.min(CAP, BASE * 2 ** k); return t / 2 + r() * t / 2; },
  "decorrelated": (k, prev, r) => Math.min(CAP, BASE + r() * (prev * 3 - BASE)),
};
console.log("strategy      calls  peak/100ms  peak/s  all done   calls in each of the first 8 s");
for (const [name, wait] of Object.entries(WAIT)) {
  const r = mulberry32(7), served = new Map(), inSlot = new Map(), perSec = [];
  const pending = [];
  let calls = 0, last = 0;
  for (let id = 0; id < CLIENTS; id++) { const d = wait(1, BASE, r); pending.push({ t: d, k: 1, prev: d }); }
  while (pending.length) {
    pending.sort((a, b) => a.t - b.t);
    const c = pending.shift(), slot = Math.floor(c.t / SLOT), sec = Math.floor(c.t);
    calls++; perSec[sec] = (perSec[sec] || 0) + 1; inSlot.set(slot, (inSlot.get(slot) || 0) + 1);
    if ((served.get(slot) || 0) < PER_SLOT) { served.set(slot, (served.get(slot) || 0) + 1); last = c.t; continue; }
    const d = wait(c.k + 1, c.prev, r);         // rejected: wait, then retry number k + 1
    pending.push({ t: c.t + d, k: c.k + 1, prev: d });
  }
  const hist = Array.from({ length: 8 }, (_, s) => String(perSec[s] || 0).padStart(4)).join("");
  console.log(name.padEnd(12) + String(calls).padStart(7) + String(Math.max(...inSlot.values())).padStart(12) +
    String(Math.max(...perSec.filter(Boolean))).padStart(8) + (last.toFixed(1) + " s").padStart(10) + "  " + hist);
}

strategy      calls  peak/100ms  peak/s  all done   calls in each of the first 8 s
no jitter      2550         100     100   462.4 s   100  98  96   0   0   0  94   0
full jitter     347          38     202     8.8 s   202  67  27  22  16   3   4   5
equal jitter    372          57     167    19.5 s   167  51  62  14  29  19   0   2
decorrelated    333          31     142     9.8 s   142  80  48  31  14   5   6   0

তিনটি ব্যবহারিক কথা। Cap রাখুন, নইলে দশম retry-র অপেক্ষা ঘণ্টায় গড়ায়; আর সর্বোচ্চ চেষ্টার সংখ্যা বা মোট সময়ের একটি সীমাও। Backoff একা overload থামায় না: পর্ব ১৮-এর simulator দেখিয়েছে, টানা overload-এ প্রত্যেকে তবুও সব কটি চেষ্টা করে, তাই গড় চাপ একই থাকে — budget বা circuit breaker লাগে। আর নিয়মটি library-তে বাঁধুন: প্রতিটি দল নিজে retry লিখলে কেউ না কেউ jitter ভুলবেই; মোবাইলের reconnect (পর্ব ১০) আর webhook (পর্ব ৩২)-এও একই নিয়ম।

৫ · Hedged request — retry নয়, tail ছাঁটার কৌশল

Retry ব্যর্থতার পরে আসে; কিন্তু প্রায়ই সমস্যা ধীরতা — ১০০টির একটি উত্তর GC pause-এ দশ গুণ দেরিতে আসে। Jeffrey Dean আর Luiz André Barroso ২০১৩ সালে Communications of the ACM-এ “The Tail at Scale” প্রবন্ধে দেখান, বহু সার্ভারে ছড়ানো (fan-out) একটি অনুরোধে এই বিরল ধীরতাই প্রায় নিয়ম হয়ে দাঁড়ায় — ১০০টি অংশের প্রত্যেকে ১% সময় ধীর হলে পুরো অনুরোধের প্রায় ৬৩% ধীর (১ − ০.৯৯^১০০; পর্ব ৪)।

তাঁদের প্রস্তাবিত একটি কৌশল hedged request: উত্তর প্রত্যাশিত সময়ের মধ্যে — যেমন এই ধরনের অনুরোধের p95 — না এলে একই অনুরোধ আরেকটি replica-তে পাঠানো; যে আগে উত্তর দেয় সেটি নেওয়া, অন্যটি বাতিল। পর্ব ৪-এর simulator-এ এতে p99 প্রায় ২০০ থেকে ৬২ ms-এ নেমেছিল, দাম মাত্র প্রায় ৫% বাড়তি অনুরোধ। প্রবন্ধটি আরও সূক্ষ্ম একটি রূপও বর্ণনা করে — tied request: অনুরোধ একসাথে দুই সার্ভারের queue-তে, প্রত্যেকে অন্যটির খবর রাখে; যে আগে কাজ শুরু করে, সে অন্যটিকে বাতিল করায়। Queue-তে অপেক্ষাই যেখানে ধীরতার কারণ, সেখানে এটি বাড়তি কাজ আরও কমায়।

gRPC-র service config-এ retryPolicy-র পাশে hedgingPolicy-ও আছে, দুটিই একই retry throttling-এ গোনা (সমর্থন সংস্করণভেদে আলাদা) — hedge আর retry একই বাজেট থেকে খরচ করে।

৬ · Circuit breaker — closed, open আর half-open

বাড়ির মিটারের পাশের circuit breaker short circuit হলে নিজেই লাইন কেটে দেয়; মিস্ত্রি পরে আবার তোলেন, সমস্যা থাকলে আবার পড়ে। সফটওয়্যারের circuit breaker-ও একটি dependency বারবার ব্যর্থ হলে কিছুক্ষণ তাকে ডাকাই বন্ধ রাখে — caller সঙ্গে সঙ্গে ত্রুটি বা fallback পায়, thread আটকায় না, আর অসুস্থ dependency সেরে ওঠার সুযোগ পায়।

Michael Nygard-এর বই Release It! (প্রথম সংস্করণ ২০০৭, দ্বিতীয় ২০১৮) circuit breaker, bulkhead আর timeout-কে “stability pattern” হিসেবে জনপ্রিয় করে (ইতিহাস ভাবনার প্রশ্ন ৪-এ)। তিনটি অবস্থা:

খোলার সিদ্ধান্ত নেয় failure-rate threshold: window-এ ব্যর্থতার অনুপাত সীমা (ধরা যাক ৫০%) ছুঁলে, সাথে একটি সর্বনিম্ন call-সংখ্যা, যাতে দুটির একটি ব্যর্থ হলেই না খোলে। Timeout আর খুব ধীর call-ও ব্যর্থতা হিসেবে গোনা ভালো; কিন্তু 400 বা 404-এর মতো client-এর ভুল নয়।

এবার একটি দীর্ঘ call-ধারায়: সেকেন্ডে ৫০টি call, ৬০ সেকেন্ড; dependency ১০ থেকে ৩০ সেকেন্ড ঝুলে থাকে। Window শেষ ২০টি, সর্বনিম্ন ১০টি, সীমা ৫০%, cool-down ৫ সেকেন্ড, ৩টি probe.

// 50 calls/s for 60 s. Normally a call takes ~20 ms and fails 2% of the time. From t = 10 s
// to t = 30 s the dependency hangs: every call waits for the 1 s timeout and fails.
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 r = mulberry32(5), TIMEOUT = 1, WINDOW = 20, MIN_CALLS = 10, THRESHOLD = 0.5, COOL = 5, PROBES = 3;
let state = "CLOSED", openedAt = 0, recent = [], probesSent = 0, probesOk = 0;
let pending = [], scOutage = 0, scHealthy = 0, waited = 0, sent = 0;
const go = (to, t, why) => { console.log(t.toFixed(2).padStart(6) + " s  " + state.padEnd(10) + "-> " + to.padEnd(10) + why);
  state = to; if (to === "OPEN") openedAt = t; if (to === "HALF_OPEN") probesSent = probesOk = 0; if (to === "CLOSED") recent = []; };
function settle(res) {                                // a call finished: update the breaker
  if (state === "HALF_OPEN" && res.probe) {
    if (!res.ok) return go("OPEN", res.end, "a probe failed");
    if (++probesOk === PROBES) go("CLOSED", res.end, PROBES + " probes succeeded");
  } else if (state === "CLOSED") {
    recent.push(res.ok); if (recent.length > WINDOW) recent.shift();
    const rate = recent.filter(ok => !ok).length / recent.length;
    if (recent.length >= MIN_CALLS && rate >= THRESHOLD)
      go("OPEN", res.end, "failure rate " + (100 * rate).toFixed(0) + "% of last " + recent.length);
  }
}
for (let t = 0; t < 60; t += -Math.log(1 - r()) / 50) {
  pending.sort((a, b) => a.end - b.end);
  while (pending.length && pending[0].end <= t) settle(pending.shift());
  if (state === "OPEN" && t - openedAt >= COOL) go("HALF_OPEN", t, "cool-down of " + COOL + " s over");
  const probe = state === "HALF_OPEN" && probesSent < PROBES;
  const hung = t >= 10 && t < 30;
  if (state === "OPEN" || (state === "HALF_OPEN" && !probe)) { hung ? scOutage++ : scHealthy++; continue; } // fallback
  if (probe) probesSent++;
  const ok = !hung && r() >= 0.02, dur = hung ? TIMEOUT : 0.01 + r() * 0.02;
  sent++; waited += dur; pending.push({ end: t + dur, ok, probe });
}
console.log("calls sent " + sent + "; short-circuited: " + scOutage + " during the outage, " + scHealthy + " after it ended");
console.log("thread-seconds spent waiting: " + waited.toFixed(0) + " with the breaker, about " +
  (waited + scOutage * TIMEOUT + scHealthy * 0.02).toFixed(0) + " without it");

 11.34 s  CLOSED    -> OPEN      failure rate 50% of last 20
 16.35 s  OPEN      -> HALF_OPEN cool-down of 5 s over
 17.35 s  HALF_OPEN -> OPEN      a probe failed
 22.36 s  OPEN      -> HALF_OPEN cool-down of 5 s over
 23.36 s  HALF_OPEN -> OPEN      a probe failed
 28.37 s  OPEN      -> HALF_OPEN cool-down of 5 s over
 29.37 s  HALF_OPEN -> OPEN      a probe failed
 34.41 s  OPEN      -> HALF_OPEN cool-down of 5 s over
 34.46 s  HALF_OPEN -> CLOSED    3 probes succeeded
calls sent 1890; short-circuited: 950 during the outage, 227 after it ended
thread-seconds spent waiting: 108 with the breaker, about 1063 without it

Library-তে এটি দেখতে কেমন

Java-র জনপ্রিয় open-source library resilience4j-এ (Hystrix-এর পরে আসা, তার দ্বারা অনুপ্রাণিত) উপরের নিয়মগুলো config-এ লেখা যায়। নিচের মানগুলো এই পর্বের উদাহরণের, library-র ডিফল্ট নয়:

resilience4j:
  circuitbreaker:
    instances:
      offers:
        slidingWindowType: COUNT_BASED
        slidingWindowSize: 20              # last 20 calls
        minimumNumberOfCalls: 10
        failureRateThreshold: 50           # percent
        slowCallDurationThreshold: 500ms   # a call slower than this counts as "slow"
        slowCallRateThreshold: 50          # percent of slow calls that also opens it
        waitDurationInOpenState: 5s        # cool-down
        permittedNumberOfCallsInHalfOpenState: 3
  bulkhead:
    instances:
      offers:
        maxConcurrentCalls: 10             # at most 10 calls to "offers" at once
        maxWaitDuration: 0ms               # no free slot: fail fast
  retry:
    instances:
      offers:
        maxAttempts: 2                     # 1 try + 1 retry
        waitDuration: 200ms

Breaker বনাম outlier ejection — আর নামের বিভ্রান্তি

Breaker সাধারণত পুরো dependency-র জন্য একটি — “অফার সার্ভিস অসুস্থ”। কিন্তু সমস্যা প্রায়ই একটিমাত্র instance-এ। তখন ভালো উপায় সেই instance-কে load balancing pool থেকে কিছুক্ষণ সরানো — outlier ejection (পর্ব ১৪-এর passive health check-এর উন্নত রূপ), একসাথে কত শতাংশ সরানো যাবে তার সীমাসহ।

৭ · Bulkhead আর cell — ব্যর্থতাকে এক কক্ষে আটকে রাখা

জাহাজের খোল কয়েকটি পানিরোধী কক্ষে (bulkhead) ভাগ করা; একটিতে ফুটো হলে শুধু সেটিই ভরে। অংশ ১-এর রেস্তোরাঁয় এর মানে: ১০ জন ওয়েটারের সর্বোচ্চ ২ জন মিষ্টির কাউন্টারে যাবেন — দই দেরি হলেও চা ঠিকই আসবে।

সফটওয়্যারে bulkhead মানে প্রতিটি dependency-র আলাদা সীমিত সম্পদ: আলাদা thread pool, বা একসাথে-চলা call-এর সর্বোচ্চ সংখ্যা (semaphore); আলাদা connection pool আর queue-ও একই ভাবনা। আকার Little-এর সূত্রে: ভাগ ≈ call-এর হার × স্বাভাবিক p99 latency × কিছুটা বাড়তি জায়গা।

সংখ্যায়: ৪০টি thread, দুটি dependency, প্রতিটিতে সেকেন্ডে ৩০০ call. “profile” সুস্থ (প্রায় ২০ ms, দরকার ৩০০ × ০.০২ = ৬টি thread); ৫ সেকেন্ড থেকে “offers” ০.২–১.০ সেকেন্ড নেয়, timeout ০.৫ সেকেন্ড। Thread না পেলে call সাথে সাথে ফেরত।

// One service, 40 worker threads, calls two dependencies: "profile" (healthy, ~20 ms) and
// "offers" (~20 ms, but from t = 5 s it takes 0.2-1.0 s; our timeout cuts it at 0.5 s).
// 300 calls/s to each. No free thread -> the call is rejected at once.
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 RATE = 300, END = 20, TIMEOUT = 0.5;
function run(pools) {                           // pools: { name: thread count }, or one shared
  const r = mulberry32(48), busy = {}, stat = { profile: [0, 0], offers: [0, 0] };
  for (const [name, n] of Object.entries(pools)) busy[name] = new Array(n).fill(0); // busy-until
  const calls = [];
  for (const dep of ["profile", "offers"])
    for (let t = 0; t < END; t += -Math.log(1 - r()) / RATE) calls.push({ t, dep });
  calls.sort((a, b) => a.t - b.t);
  for (const { t, dep } of calls) {
    const pool = busy[dep] || busy.shared, i = pool.findIndex(u => u <= t), count = t >= 5;
    if (count) stat[dep][1]++;                  // count only after "offers" got slow
    if (i < 0) continue;                        // no thread free: rejected at once
    const slow = dep === "offers" && t >= 5, took = slow ? 0.2 + r() * 0.8 : 0.01 + r() * 0.02;
    pool[i] = t + Math.min(took, TIMEOUT);      // the thread is held until reply or timeout
    if (count && took <= TIMEOUT) stat[dep][0]++;
  }
  const pct = ([ok, all]) => (100 * ok / all).toFixed(1).padStart(6) + "%";
  return pct(stat.profile) + "   " + pct(stat.offers);
}
console.log("thread pools (t = 5..20 s)            profile ok  offers ok");
console.log("one shared pool of 40               " + run({ shared: 40 }));
console.log("bulkheads: profile 20, offers 20    " + run({ profile: 20, offers: 20 }));
console.log("bulkheads: profile 30, offers 10    " + run({ profile: 30, offers: 10 }));

thread pools (t = 5..20 s)            profile ok  offers ok
one shared pool of 40                 30.1%     11.5%
bulkheads: profile 20, offers 20     100.0%      5.7%
bulkheads: profile 30, offers 10     100.0%      3.2%

বড় মাপের bulkhead — cell আর shuffle sharding

একই ভাবনা পুরো সেবার স্তরে নিলে আসে cell-based architecture: পুরো stack-এর (সার্ভিস, database, queue) কয়েকটি স্বাধীন, একই রকম কপি — cell — আর প্রতিটি ব্যবহারকারী একটি নির্দিষ্ট cell-এ। একটি খারাপ deploy বা database-এর বিপর্যয় শুধু সেই cell-কে ছোঁয়; blast radius ধরা যাক ১০ ভাগের ১ ভাগ। দাম: সামনে একটি routing স্তর, cell-এর মধ্যে ডেটা সরানোর জটিলতা আর চালানোর বাড়তি কাজ। AWS-এর প্রকাশিত নির্দেশিকায় cell আর shuffle sharding-এর আলোচনা আছে। Shuffle sharding-এ প্রতিটি client পায় সব সার্ভারের বদলে এলোমেলো ছোট একটি দল: ৮টি সার্ভার থেকে ২টি করে নিলে ২৮ রকম জোড়া হয়, তাই একটি client-এর খারাপ traffic যে দুটি সার্ভার বসায়, অন্য একটি নির্দিষ্ট client-এর দুটিই সেগুলো হওয়ার সম্ভাবনা ২৮-এ ১।

৮ · Fallback, graceful degradation আর health check-এর ফাঁদ

Breaker খুলল, timeout পেরোল — ব্যবহারকারী কী দেখবেন? “500” সবচেয়ে সহজ, আর প্রায়ই সবচেয়ে খারাপ উত্তর। ভালো নকশা প্রতিটি dependency-র জন্য আগেই ঠিক করে: এটি না পেলে কী হবে। পর্ব ১৮-এর graceful degradation-এর হাতিয়ারের মধ্যে এখানে তিনটি সবচেয়ে কাজের:

তিনটি নিয়ম। Fallback-ও একটি dependency — সেটি যেন একই অসুস্থ অংশের ওপর নির্ভর না করে, আর নিজে দামি না হয়। Fail open নাকি fail closed, তা ব্যবসার সিদ্ধান্ত: সুপারিশ না এলে পাতা দেখানো ঠিক, কিন্তু অনুমতি-যাচাই না এলে প্রবেশ দেওয়া বিপজ্জনক। আর যে fallback কখনো চলেনি, সেটি সম্ভবত কাজ করে না — তাই অংশ ৯-এর পরীক্ষা। Overload-এ fallback-এর আগের ধাপ load shedding (পর্ব ১৮), আর client-প্রতি সীমা পরের পর্বে (পর্ব ৪৯)।

Health check — রক্ষাকবচ যখন নিজেই আঘাত করে

পর্ব ১৪-এ health check-এর হিসাব দেখেছেন। Resilience-এর চোখে এর বিপদ একটিই: ভাগ করা dependency-র সমস্যা যদি সব instance-এর check-কে একসাথে ব্যর্থ করে। ধরা যাক প্রতিটি instance-এর /health database-এ একটি query চালায়। Database একটু ধীর হলো, ২ সেকেন্ডের check timeout পেরোল। Load balancer সব instance-কে একসাথে বাদ দিল — database-এর সামান্য ধীরতা এখন পুরো সেবার বিভ্রাট। এর নাম deep health check-এর ফাঁদ।

আরও দুটি রক্ষাকবচ: প্রায় সবাইকে অসুস্থ দেখলে অনেক load balancer fail open করে (পর্ব ১৪), কারণ “সবাই মৃত” সাধারণত check-এরই ভুল; আর health endpoint-কে আলাদা ছোট thread দিন, যাতে pool ভরলেও “বেঁচে আছি, কিন্তু ব্যস্ত” জানানো যায়।

৯ · Chaos engineering, game day আর library বনাম service mesh

অগ্নিনির্বাপণের মহড়া ছাড়া কেউ জানেন না বিপদের সিঁড়ি তালাবন্ধ কি না; timeout আর fallback কাজ করে কি না, তা প্রথম আসল বিভ্রাটে জানলে দেরি। Chaos engineering মানে নিয়ন্ত্রিত পরীক্ষায় ইচ্ছা করে ব্যর্থতা ঘটিয়ে দেখা।

প্রকাশিত ইতিহাস অনুযায়ী Netflix ২০১০ সালের দিকে Chaos Monkey বানায়, যা কাজের সময়ে এলোমেলোভাবে production-এর instance বন্ধ করত; ২০১২ সালে এটি open-source হয়। পরে নীতিগুলো “Principles of Chaos Engineering” নামে প্রকাশিত হয়:

1. Steady state-এর অনুমান: “স্বাভাবিক” একটি মাপা সংখ্যায় — যেমন সফল অর্ডারের হার।
2. বাস্তব ঘটনার মতো ব্যর্থতা: সার্ভার বন্ধ, ৫০০ ms দেরি, একটি zone বিচ্ছিন্ন।
3. যতটা সম্ভব বাস্তব পরিবেশে, কারণ staging-এর traffic আলাদা।
4. স্বয়ংক্রিয় আর নিয়মিত।
5. ছোট blast radius: ১% traffic বা একটি cell থেকে শুরু, থামানোর বোতামসহ।

হাতিয়ারটি প্রায়ই fault injection: service mesh বা library দিয়ে, যেমন ১০% অনুরোধে 503 ফেরত বা ২ সেকেন্ড বাড়তি দেরি। মানুষের দিকটা পরীক্ষা করে game day: ঘোষিত দিনে পরিকল্পিত বিভ্রাট ঘটিয়ে দেখা alert বাজে কি না, runbook ঠিক কি না, কে কাকে ডাকে (Amazon-এর GameDay-র ইতিহাস ভাবনার প্রশ্ন ৫-এ)।

Resilience কোথায় থাকবে — library, নাকি service mesh?

Library-স্তরে অ্যাপের কোডে resilience4j বা Polly; mesh-স্তরে প্রতিটি সার্ভিসের পাশের sidecar proxy (যেমন Envoy) সব call-এ নিয়ম প্রয়োগ করে, config কেন্দ্রীয় — service mesh, যেমন Istio বা Linkerd (পর্ব ৪৭)।

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: offers
spec:
  hosts: ["offers"]
  http:
  - route:
    - destination: { host: offers }
    timeout: 800ms                  # whole call, all tries included
    retries:
      attempts: 1
      perTryTimeout: 300ms
      retryOn: connect-failure,refused-stream,unavailable
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: offers
spec:
  host: offers
  trafficPolicy:
    connectionPool:                 # bulkhead-like limits
      http: { http1MaxPendingRequests: 20, maxRequestsPerConnection: 50 }
    outlierDetection:               # eject a bad instance for a while
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 30

অনেক দল দুটি মেশায়: সাধারণ timeout, সংযোগ-স্তরের retry আর outlier ejection mesh-এ; fallback, idempotency key আর ব্যবসা-বোঝা breaker অ্যাপে। শর্ত একটাই: retry কোন স্তরে, তা এক জায়গায় লিখিত থাকুক। আর মনে রাখুন, Netflix-এর Hystrix ২০১৮ সালে maintenance mode-এ গেছে — library বদলায়, pattern টিকে থাকে।

১০ · AI-এর যুগে resilience-নকশা যাচাই

“আমাদের সার্ভিসগুলো মাঝে মাঝে একসাথে বসে যায়” — AI প্রায় নিশ্চিতভাবে বলবে “retry, circuit breaker আর Kafka যোগ করুন”। সংখ্যা ছাড়া তা নকশা নয়। সাধারণ ভুলগুলো:

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

• প্রতিটি timeout-এর জন্য λ × timeout নিজে হিসাব করে pool-এর সাথে মিলিয়েছি, আর timeout শিকলের নিচে ছোট হয়েছে
• Retry শুধু একটি স্তরে, শুধু ক্ষণিকের ত্রুটিতে আর idempotent কাজে; kⁿ গুণফল আর retry budget হিসাব করেছি
• Backoff-এ jitter আর cap আছে; deadline পেরোলে আর চেষ্টা নেই
• প্রতিটি dependency-র bulkhead, breaker-এর সীমা আর স্বাধীন fallback লেখা আছে
• Library বা mesh-এর প্রতিটি নাম ও ডিফল্ট অফিসিয়াল documentation-এ মিলিয়েছি
• Simulation বা staging-এ fault injection চালিয়ে দেখেছি — একটি dependency ধীর হলেও বাকিরা টেকে