Monolith বনাম microservices — service boundary, service discovery আর service mesh

১ · মডিউল ৮-এর শুরু — নকশা থেকে চালানোর দিকে

গত সাতটি মডিউলে আপনি টুকরোগুলো চিনেছেন: API, load balancer, database, cache, queue আর distributed system-এর তত্ত্ব। এই মডিউলের প্রশ্ন: সেই টুকরো দিয়ে বানানো আসল সিস্টেম দিনের পর দিন কীভাবে চলবে, বদলাবে আর বিপদে টিকবে? পথটি এরকম:

সবগুলোর গোড়ায় একটি সিদ্ধান্ত: সিস্টেমটি কি একটি প্রোগ্রাম, না অনেক ছোট প্রোগ্রাম যারা network-এ কথা বলে? এই উত্তরই ঠিক করে পরের পর্বগুলোর সমস্যা কত বড় — দশটি সেবা মানে timeout-retry-র প্রশ্ন দশ গুণ, pipeline-ও দশটি।

২ · Monolith — একটি deployable, আর modular monolith কেন শক্ত শুরু

Monolith মানে পুরো অ্যাপ্লিকেশন একটি deployable — একটি প্রোগ্রাম বা package, যা একসাথে build, test আর deploy হয়। অর্ডার, পেমেন্ট, পণ্যের তালিকা, ব্যবহারকারী — সবার কোড একই process-এ চলে, আর সাধারণত একটি database ব্যবহার করে। শব্দটির আসল অর্থ শুধু “একসাথে deploy হয়” — জট পাকানো কোড নয়; ভেতরে পরিষ্কার ভাগ থাকতেই পারে।

Monolith-এর সুবিধাগুলো এত স্বাভাবিক যে চোখে পড়ে না:

• ডাকা সস্তা: এক module আরেকটিকে ডাকে সাধারণ function call দিয়ে — কয়েক ন্যানোসেকেন্ডের ব্যাপার। একই data center-এ একটি network round trip প্রায় অর্ধ মিলিসেকেন্ড (পর্ব ৩-এর সংখ্যা), অর্থাৎ প্রায় এক লাখ গুণ বেশি — তার ওপর serialization, timeout আর ব্যর্থতার ঝুঁকি।
• এক transaction: অর্ডার লেখা আর stock কমানো এক database transaction-এ করা যায় — পর্ব ২৪-এর ACID-এর পুরো সুবিধা। Microservices-এ একই কাজে লাগে saga আর outbox (পর্ব ২৫)।
• সহজ debugging আর operations: একটি stack trace পুরো গল্প বলে; pipeline আর monitoring একটিই।

সমস্যা দেখা দেয় সিস্টেম আর দল বড় হলে। পঞ্চাশজন developer একই কোডে কাজ করলে প্রতিটি deploy-এ অনেকের পরিবর্তন একসাথে যায়; একজনের ভুলে সবার release আটকে থাকে। পণ্য খোঁজার অংশে দশ গুণ বেশি চাপ, অথচ scale করতে হয় পুরো প্রোগ্রাম (পর্ব ১৩)। একটি module-এর memory leak পুরো process বসিয়ে দেয় — পেমেন্টও বন্ধ। আর ভাগের নিয়ম শুধু মুখে থাকলে কয়েক বছরে সবাই সবার ভেতরের function ডাকতে শুরু করে — একে বলে “big ball of mud”.

Modular monolith — এক deploy, কিন্তু শক্ত দেয়াল

মাঝামাঝি পথটি অনেক অভিজ্ঞ প্রকৌশলীর প্রথম পছন্দ: deploy একটিই, কিন্তু module-গুলোর মাঝে নিয়মের দেয়াল শক্ত।

• প্রতিটি module-এর একটি public interface; অন্যরা শুধু সেটিই ডাকতে পারে, ভেতরের class বা function নয় — build-এর সময় একটি নিয়ম-পরীক্ষক দিয়ে এটি জোর করে মানানো যায়।
• প্রতিটি module-এর নিজের টেবিল (আলাদা schema); অন্য module-এর টেবিলে সরাসরি SQL নিষেধ।
• Module-এর মাঝে যোগাযোগ যতটা পারা যায় ঘটনা (event) বা স্পষ্ট interface দিয়ে।

আজ আপনি monolith-এর সরলতা পান; কাল কোনো module-কে আলাদা সেবা বানাতে হলে তার সীমানা আর ডেটা আগেই আলাদা।

৩ · Microservices — আলাদা deploy, নিজের ডেটা, আর network-এর দাম

Microservices-এ অ্যাপটি অনেকগুলো ছোট সেবায় ভাগ, যারা network-এ API বা বার্তা দিয়ে কথা বলে। “ছোট” মানে কোডের লাইন নয়; সংজ্ঞার দুটি মূল শর্ত:

1. আলাদাভাবে deploy করা যায় (independent deployability): পেমেন্ট দল নিজের সেবা আজ দুপুরে বদলাতে পারে, অর্ডার দলকে না জানিয়েই — যতক্ষণ API-র চুক্তি ঠিক থাকে।
2. নিজের ডেটার মালিক (database per service): প্রতিটি সেবার ডেটা শুধু সে নিজে পড়ে-লেখে; অন্যরা তার API বা event-এর মাধ্যমে জানে।

এই দুই শর্তের একটি ভাঙলে বাকি সুবিধাও ভাঙে। ২০১৪ সালে James Lewis আর Martin Fowler-এর একটি বহুল-পঠিত লেখা নামটি জনপ্রিয় করে, যদিও ধারণাগুলো আগের service-oriented architecture-এর অভিজ্ঞতাতেও ছিল।

আসল লাভ — আর তার শর্ত

প্রতিটি লাভের শর্ত আছে। অর্ডার সেবা রিভিউর উত্তরের জন্য timeout ছাড়া অপেক্ষা করলে, রিভিউ ধীর হলে অর্ডারের থ্রেডও আটকে যায় — isolation-এর বদলে cascading failure (প্রতিরক্ষা পর্ব ৪৮-এ)।

আসল দাম

Network-এর দাম সংখ্যায় — fan-out, tail latency আর composite availability

ধরা যাক একটি অনুরোধ পূরণ করতে N টি সেবাকে ডাকতে হয়, আর প্রত্যেককেই উত্তর দিতে হবে।

Availability — গুণফল. প্রতিটি সেবা স্বাধীনভাবে a_i সম্ভাবনায় সচল থাকলে, সবাই একসাথে সচল থাকার সম্ভাবনা গুণফল — এটিই composite availability (পর্ব ৫-এর serial হিসাব)। পরপর ডাকুন বা একসাথে, সবাইকে লাগলে হিসাব একই:

সহজ আন্দাজ: a = 1 − ε হলে a^N ≈ 1 − Nε, অর্থাৎ ব্যর্থতার অংশ মোটামুটি যোগ হয়। প্রতিটির ০.১% বিভ্রাট, ২০টি সেবা → প্রায় ২%, মাসে প্রায় ১৪ ঘণ্টা (একটির ০.১% মানে মাসে প্রায় ৪৩ মিনিট)। উল্টো দিকে, যেকোনো একটি সচল থাকলেই চললে (একই সেবার k টি copy) A = 1 − (1 − a)^k — redundancy availability বাড়ায়, শিকল কমায়।

Latency — যোগফল বনাম সবচেয়ে ধীরটি. সেবাগুলোকে পরপর (sequential) ডাকলে মোট সময় সবার যোগফল। একসাথে (parallel) ডাকলে মোট সময় সবচেয়ে ধীর উত্তরের সময়। Parallel দ্রুত, কিন্তু এখানেও একটি ফাঁদ আছে — tail. ধরুন প্রতিটি call ১% সময় ধীর। N টি call-এর অন্তত একটি ধীর হওয়ার সম্ভাবনা

অর্থাৎ প্রতিটি সেবার p99-এর ধীরতা, ২০টি fan-out-এ প্রায় প্রতি ৫টি অনুরোধে ১টির অভিজ্ঞতা হয়ে যায় — পর্ব ৪-এর fan-out বৃদ্ধি। নিচের simulator প্রতিটি call-এর latency বানায় সাধারণত ৫–১১ ms, আর ১% ক্ষেত্রে ৫০–২৫০ ms; প্রতিটি সেবা ৯৯.৯% সময় সচল। ২০,০০০টি অনুরোধে N = ১, ৫, ১০, ২০-এর জন্য p50, p99 আর সবাই-সচল অনুরোধের অংশ মাপে।

// One user request calls N services. Each call: ~8 ms usually, 1% slow (50-250 ms),
// and each service is up 99.9% of the time. Sequential = sum, parallel = slowest one.
let seed = 47; function rand() {      // mulberry32: seeded PRNG
  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 call = () => rand() < 0.01 ? 50 + 200 * rand() : 5 + 6 * rand();   // ms
const pct = (a, p) => a[Math.ceil(p / 100 * a.length) - 1];              // nearest rank
const R = 20000;
console.log(" N" + "seq p50".padStart(17) + "p99".padStart(9) + "par p50".padStart(15) +
  "p99".padStart(9) + "all-up formula".padStart(15) + "simulated".padStart(11));
for (const N of [1, 5, 10, 20]) {
  const seq = [], par = []; let ok = 0;
  for (let r = 0; r < R; r++) {
    let sum = 0, max = 0, up = true;
    for (let i = 0; i < N; i++) {
      const ms = call(); sum += ms; if (ms > max) max = ms;
      if (rand() >= 0.999) up = false;          // this service is down right now
    }
    seq.push(sum); par.push(max); if (up) ok++;
  }
  seq.sort((a, b) => a - b); par.sort((a, b) => a - b);
  const f = x => x.toFixed(0).padStart(5) + " ms";
  console.log(String(N).padStart(2) + "  " + f(pct(seq, 50)).padStart(15) + f(pct(seq, 99)).padStart(9) +
    f(pct(par, 50)).padStart(15) + f(pct(par, 99)).padStart(9) +
    ((0.999 ** N) * 100).toFixed(2).padStart(14) + "%" + (ok / R * 100).toFixed(2).padStart(10) + "%");
}

 N          seq p50      p99        par p50      p99 all-up formula  simulated
 1             8 ms    11 ms           8 ms    11 ms         99.90%     99.91%
 5            40 ms   241 ms          10 ms   206 ms         99.50%     99.56%
10            81 ms   306 ms          11 ms   230 ms         99.00%     99.00%
20           162 ms   420 ms          11 ms   240 ms         98.02%     97.97%

৪ · Service boundary — Conway-এর সূত্র, bounded context আর ডেটার মালিকানা

Conway-এর সূত্র — সিস্টেম দলের ছবি আঁকে

১৯৬৮ সালে Melvin Conway একটি প্রবন্ধে (প্রকাশিত হয় Datamation পত্রিকায়, এমনটাই সাধারণত উল্লেখ করা হয়) একটি পর্যবেক্ষণ লেখেন, যা পরে Conway-এর সূত্র নামে পরিচিত হয়: যে প্রতিষ্ঠান একটি সিস্টেম নকশা করে, তার নকশা সেই প্রতিষ্ঠানের যোগাযোগের কাঠামোর মতো হতে বাধ্য। প্রচলিত একটি উদাহরণে: চারটি দল একটি compiler বানালে তাতে চারটি ধাপ (pass) থাকবে। Fred Brooks তাঁর ১৯৭৫ সালের বই The Mythical Man-Month-এ এটিকে “Conway’s law” নামে উল্লেখ করে আরও পরিচিত করেন।

কারণটি সহজ: দুটি module-এর মাঝে interface মানে দুই দলের মাঝে চুক্তি। রোজ একসাথে বসা দুই দলের কোডে সীমানা ঝাপসা হয়; আলাদা বিভাগের দুই দলের মাঝে সীমানা শক্ত হয়ে যায়। তাই microservices-এর সিদ্ধান্ত অনেকটাই প্রতিষ্ঠানের নকশা:

• পাঁচজনের একটি দল বিশটি সেবা বানালে, প্রত্যেকের মাথায় চারটি সেবার deploy, alert আর on-call — দলের কাঠামোর সাথে সিস্টেমের মিল নেই, তাই ঘর্ষণ।
• উল্টো দিকে, দশটি দল এক monolith-এ কাজ করলে release-এর দিন সবাই একে অপরের পথে।
• Inverse Conway maneuver: যে architecture চান, আগে সেই আকারে দল সাজান — প্রতিটি bounded context-এর জন্য একটি দীর্ঘস্থায়ী দল, যারা নিজের সেবার শুরু থেকে শেষ পর্যন্ত মালিক।

২০১৯ সালের একটি প্রভাবশালী বই Team Topologies (Matthew Skelton ও Manuel Pais) এই চিন্তাকে আরও এগিয়ে নেয়: দলের ওপর মানসিক ভার (cognitive load) সীমিত রাখা, আর প্রতিটি সেবার মালিক ঠিক একটি দল। একটি সেবার দুই মালিক মানে কার্যত কোনো মালিক নেই।

কোথায় কাটবেন — কাজ ধরে, স্তর ধরে নয়

সবচেয়ে প্রচলিত ভুল হলো প্রযুক্তির স্তর ধরে কাটা — “UI সেবা”, “logic সেবা”, “database সেবা”; তখন প্রতিটি নতুন feature-এ তিনটিই বদলাতে আর একসাথে deploy করতে হয়। কাটতে হয় ব্যবসার কাজ ধরে, যাতে একটি সাধারণ পরিবর্তন একটি সেবাতেই সীমিত থাকে — ভেতরে ঘনিষ্ঠতা (cohesion) বেশি, বাইরে নির্ভরতা (coupling) কম।

Bounded context — একই শব্দ, ভিন্ন অর্থ

২০০৩ সালে Eric Evans-এর বই Domain-Driven Design (DDD) এর জন্য একটি ভাষা দেয়। একটি কাল্পনিক অনলাইন দোকানে “পণ্য” শব্দটি ভাবুন। ক্যাটালগ দলের কাছে পণ্য মানে নাম, ছবি আর বর্ণনা; গুদাম দলের কাছে তাকের নম্বর, ওজন আর stock; দাম দলের কাছে মূল্য, ছাড় আর VAT. তিনটি এক বিশাল “Product” টেবিলে ঠাসলে প্রতিটি দল অন্যদের কলাম নিয়ে ভয়ে থাকে।

Bounded context হলো একটি সীমানা, যার ভেতরে প্রতিটি শব্দের একটিই নির্দিষ্ট অর্থ — দলের আর কোডের একই ubiquitous language. দুই context-এর মাঝে অনুবাদ হয় স্পষ্ট interface-এ; পুরোনো বা বাইরের সিস্টেমের বিদঘুটে মডেল ঠেকাতে মাঝে একটি অনুবাদক-স্তর — anti-corruption layer.

Aggregate — একসাথে বদলাতে হয় এমন জিনিস

Evans-এর আরেকটি ধারণা aggregate: কয়েকটি বস্তুর গুচ্ছ, যার নিয়ম (invariant) একসাথে সত্য রাখতে হয়, তাই যা একটি transaction-এ বদলায়। অর্ডার আর তার লাইনগুলো একটি aggregate (“মোট = লাইনগুলোর যোগফল”); অর্ডার আর গ্রাহকের wallet আলাদা aggregate, তাদের মাঝে নিয়ম রক্ষা করে saga (পর্ব ২৫)।

তাই নিয়ম: একটি aggregate কখনো দুই সেবায় ভাগ হবে না। একটি সেবায় এক বা একাধিক aggregate থাকতে পারে; সাধারণত একটি bounded context একটি সেবা দিয়ে শুরু হয়।

ডেটার মালিকানা — database per service

প্রতিটি ডেটার একজনই মালিক সেবা, যে একাই সেটি লেখে। অন্য সেবার সেই ডেটা লাগলে তিনটি পথ:

1. API-তে জিজ্ঞেস করা — সর্বশেষ মান, কিন্তু মালিক বিকল হলে আপনিও আটকে যান।
2. ঘটনা শুনে নিজের কপি রাখা — মালিক প্রকাশ করে “PriceChanged”, আর অর্ডার সেবা নিজের ছোট টেবিলে দাম রাখে (event-carried state transfer, পর্ব ৩২)। দ্রুত আর স্বাধীন, কিন্তু কপি একটু পুরোনো হতে পারে।
3. রিপোর্টের জন্য আলাদা জায়গা — সব সেবার ঘটনা বা CDC থেকে একটি data warehouse (DBMS কোর্সের data warehousing পর্ব)।

যে পথটি বন্ধ: অন্য সেবার database-এ সরাসরি ঢুকে পড়া বা লেখা। তাতে টেবিলের schema দুই সেবার গোপন চুক্তি হয়ে যায় — একটি কলামের নাম বদলালে অন্যটি ভাঙে, আর কেউ জানেই না কে কী পড়ছে।

৫ · Distributed monolith — দুই জগতের খারাপটুকু, আর sync বনাম async

সীমানা ভুল হলে যা তৈরি হয় তার নাম distributed monolith: দেখতে microservices — অনেক সেবা, অনেক container — কিন্তু আচরণে monolith, শুধু সব call এখন network-এ। Monolith-এর সরলতা নেই, microservices-এর স্বাধীনতাও নেই। চেনার তিনটি প্রধান চিহ্ন:

• বাচাল call (chatty): একটি অনুরোধে কয়েক ডজন call, আর সংখ্যাটি ডেটার আকারের সাথে বাড়ে — যেমন কার্টের প্রতিটি পণ্যের জন্য আলাদা call (database-এর N+1 সমস্যার network-রূপ)।
• ভাগের database: একটি টেবিলে কয়েকটি সেবা লেখে। এক সেবার schema বদলালে অন্যদের একসাথে বদলাতে হয়।
• Lock-step deploy: “পেমেন্ট আর অর্ডার একই দিনে, এই ক্রমে deploy করতে হবে।” আলাদা deploy-ই যদি না হয়, microservices-এর মূল লাভই নেই।

আরও চিহ্ন: লম্বা synchronous শিকল (A → B → C → D), আর সব সেবায় ব্যবসার নিয়মসহ একটি ভাগ করা library.

নিচের কোড একটি কাল্পনিক অনলাইন দোকানের “অর্ডার দেওয়া” অনুরোধের call graph আর কে কোন টেবিলে লেখে তা নিয়ে চিহ্নগুলো গোনে — আগের নকশা আর ঠিক করা নকশা পাশাপাশি। কার্টে ১ থেকে ৮টি পণ্য, ১,০০০টি অর্ডার।

// Made-up shop, "place order": a>b sync call, a>b* one call per cart item, a~b async event
let seed = 8; function rand() {      // mulberry32: seeded PRNG
  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 designs = {
  before: { edges: "gateway>order order>user order>catalog* order>pricing* pricing>catalog " +
      "order>inventory* order>payment payment>user order>notify",
    writers: { products: "catalog pricing inventory", users: "user payment", orders: "order notify" } },
  after: { edges: "gateway>order order>user order>pricing order>inventory order>payment order~notify",
    writers: { products: "catalog", prices: "pricing", stock: "inventory", users: "user", orders: "order" } },
};
function walk(edges, node, mult, k, depth, acc) {        // count sync network calls
  for (const e of edges.split(" ")) {
    const [a, b] = e.replace("*", "").split(/[>~]/); if (a !== node) continue;
    if (e.includes("~")) { acc.events++; continue; }      // fire-and-forget event
    const m = mult * (e.endsWith("*") ? k : 1);
    acc.calls += m; acc.depth = Math.max(acc.depth, depth + 1); walk(edges, b, m, k, depth + 1, acc);
  }
}
for (const [name, d] of Object.entries(designs)) {
  const runs = [];
  for (let r = 0; r < 1000; r++) {                        // 1000 orders, cart size 1-8
    const acc = { calls: 0, events: 0, depth: 0 }, items = 1 + Math.floor(rand() * 8);
    walk(d.edges, "gateway", 1, items, 0, acc); runs.push(acc);
  }
  const calls = runs.map(a => a.calls).sort((x, y) => x - y), { depth, events } = runs[0];
  const shared = Object.entries(d.writers).filter(([, w]) => w.includes(" "));
  console.log(name + ": calls/request avg " + (calls.reduce((s, x) => s + x) / 1000).toFixed(1) +
    ", max " + calls[999] + ", sync depth " + depth + ", async events " + events);
  if (calls[999] > 10) console.log("  SMELL chatty: per-item calls grow with cart size");
  if (depth >= 3) console.log("  SMELL sync chain of " + depth + " hops: latency and failures add up");
  for (const [t, w] of shared) console.log("  SMELL table '" + t + "' written by " + w + " -> lock-step deploys");
  if (!shared.length && calls[999] <= 10) console.log("  ok: one owner per table, calls stay flat");
}

before: calls/request avg 23.1, max 37, sync depth 3, async events 0
  SMELL chatty: per-item calls grow with cart size
  SMELL sync chain of 3 hops: latency and failures add up
  SMELL table 'products' written by catalog pricing inventory -> lock-step deploys
  SMELL table 'users' written by user payment -> lock-step deploys
  SMELL table 'orders' written by order notify -> lock-step deploys
after: calls/request avg 5.0, max 5, sync depth 2, async events 1
  ok: one owner per table, calls stay flat

সেবার মাঝে কথা — sync না async?

Synchronous call (REST বা gRPC, পর্ব ৮, ৯) সরল: প্রশ্ন, তারপর উত্তর। কিন্তু উত্তর না আসা পর্যন্ত ডাকা সেবাকে সচল থাকতে হয় — অংশ ৩-এর গুণফল এখানেই। Asynchronous বার্তা (পর্ব ৩১-এর queue, পর্ব ৩২-এর pub/sub) সময়ের বাঁধন খুলে দেয়: অর্ডার সেবা “OrderPlaced” প্রকাশ করে চলে যায়, নোটিফিকেশন সেবা বিকল থাকলেও বার্তা broker-এ অপেক্ষা করে — একে বলে temporal decoupling. দাম: ফল সঙ্গে সঙ্গে জানা যায় না, ক্রম আর duplicate সামলাতে হয় (পর্ব ৩৪), debugging কঠিন।

৬ · Strangler fig — monolith থেকে ধীরে ধীরে বের হওয়া

পুরো monolith একবারে নতুন করে লেখা (big-bang rewrite) একটি পরিচিত ফাঁদ: বছরের পর বছর দুটি সিস্টেম চলে, পুরোনোটির অর্ধেক আচরণ লেখা নেই, আর চালুর দিন এক ঝুঁকিতে সব। Martin Fowler ২০০৪ সালের একটি লেখায় বিকল্পটির নাম দেন strangler fig application — অস্ট্রেলিয়ার বনে দেখা এক ধরনের ডুমুর-লতার নামে, যা একটি গাছকে ঘিরে ধীরে ধীরে বেড়ে ওঠে আর শেষে পুরোনো গাছের জায়গা নেয়।

কৌশলের হৃৎপিণ্ড হলো সামনে একটি facade — সাধারণত একটি reverse proxy বা API gateway (পর্ব ১১), যা প্রতিটি পথ (route) কোথায় যাবে ঠিক করে। ব্যবহারকারী একই ঠিকানায় আসেন; পেছনে একটি একটি feature নতুন সেবায় সরে যায়। নিচে একটি কাল্পনিক দোকানের “রিভিউ ও রেটিং” feature বের করা দেখুন।

কোন feature আগে? যার সীমানা পরিষ্কার, জড়ানো কম, আর আলাদা হলে সত্যিকারের লাভ আছে — যেমন আলাদা scaling বা ঘন ঘন বদল। সবচেয়ে জড়ানো, ঝুঁকির অংশ (যেমন পেমেন্টের হিসাব) দিয়ে শুরু করা সাধারণত ভুল। আর facade নিজেও ঝুঁকি — পর্ব ১১-এর SPOF আর “smart gateway”-এর সতর্কতা মনে রাখুন।

৭ · Service discovery — কে এখন কোথায় আছে

Monolith-এ module-রা একই process-এ, খোঁজার প্রশ্নই নেই। Microservices-এ পেমেন্ট সেবার হয়তো ৬টি instance, যারা autoscaling (পর্ব ১৩) আর deploy-এর সাথে জন্মায় আর মরে, প্রতিবার নতুন IP নিয়ে — config-এ ঠিকানা লিখে রাখা অচল। দরকার একটি ব্যবস্থা, যা জানে এই মুহূর্তে কোন instance জীবিত আর কোথায় — service discovery. তার দুটি অংশ: নিবন্ধন (কে আছে) আর খোঁজা (কাকে ডাকব)।

Registry — নিবন্ধন, heartbeat আর TTL

কেন্দ্রে একটি service registry: সেবার নাম থেকে জীবিত instance-এর ঠিকানার তালিকা। প্রায়ই এটি etcd, ZooKeeper বা Consul-এর মতো একটি coordination service-এর ওপর থাকে (পর্ব ৪৩)। নিবন্ধন দুই রকম। Self-registration-এ instance নিজে চালু হয়ে নিজের ঠিকানা লেখে আর নিয়মিত heartbeat দিয়ে একটি lease নবায়ন করে; heartbeat থামলে TTL শেষে entry নিজেই মুছে যায়। Third-party registration-এ platform নিজে (যেমন Kubernetes) instance চালু-বন্ধ দেখে তালিকা হালনাগাদ করে, আর readiness পরীক্ষায় পাশ করলে তবেই তালিকায় তোলে।

TTL বাছাইয়ে পর্ব ৪৪-এর টানাপোড়েন: ছোট TTL-এ মৃত instance দ্রুত বাদ, কিন্তু ধীর heartbeat-এ জীবিতও বাদ পড়তে পারে; বড় TTL-এ উল্টো। আর client তালিকা cache করলে বদল জানে আরও দেরিতে।

এবার ঠিক সেই পরিস্থিতি simulator-এ, আর সাথে একটি client যে পরপর ৩টি ব্যর্থতায় instance-টিকে ৩০ s বাদ রাখে:

// Registry: each instance heartbeats every 5 s; an entry expires after 15 s of silence.
// Client: re-reads the registry every 10 s, sends 10 req/s round-robin. C crashes at t=20.
let seed = 4747; function rand() {   // mulberry32: seeded PRNG
  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 join = { A: 0, B: 0, C: 0, D: 12 }, phase = {}, TTL = 15, CRASH = 20, say = s => console.log("  " + s);
for (const k in join) phase[k] = Math.floor(rand() * 5);   // heartbeat offset 0-4 s
function run(eject) {          // eject: client drops an instance after 3 failures in a row
  const reg = {}, fails = {}, out = {}; let list = [], rr = 0, bad = 0;
  for (let t = 0; t <= 45; t++) {
    for (const k in join) {
      const up = !(k === "C" && t >= CRASH), d = t - join[k];
      if (up && (d === 0 || (d > 0 && d % 5 === phase[k]))) reg[k] = t;   // register / beat
    }
    for (const k in reg) if (t - reg[k] > TTL) { delete reg[k]; say("t=" + t + " registry evicts " + k); }
    if (t % 10 === 0) {
      list = Object.keys(reg).sort();
      if (!eject) say("t=" + t + " registry " + list.map(k => k + "(last " + reg[k] + ")").join(" ") +
        " -> client list " + list.join(","));
    }
    for (let i = 0; i < 10; i++) {     // 10 requests in this second
      const live = list.filter(k => !(out[k] > t)), k = live[rr++ % live.length];
      if (k !== "C" || t < CRASH) { fails[k] = 0; continue; }
      bad++; fails[k] = (fails[k] || 0) + 1;
      if (eject && fails[k] === 3) { out[k] = t + 30; say("t=" + t + " client ejects C after 3 fails"); }
    }
  }
  return bad;
}
console.log("heartbeat offsets " + JSON.stringify(phase));
for (const eject of [false, true]) {
  console.log(eject ? "--- plus passive ejection" : "--- registry + 10 s client refresh");
  say("requests sent to dead C: " + run(eject));
}

heartbeat offsets {"A":2,"B":0,"C":4,"D":0}
--- registry + 10 s client refresh
  t=0 registry A(last 0) B(last 0) C(last 0) -> client list A,B,C
  t=10 registry A(last 7) B(last 10) C(last 9) -> client list A,B,C
  t=20 registry A(last 17) B(last 20) C(last 19) D(last 17) -> client list A,B,C,D
  t=30 registry A(last 27) B(last 30) C(last 19) D(last 27) -> client list A,B,C,D
  t=35 registry evicts C
  t=40 registry A(last 37) B(last 40) D(last 37) -> client list A,B,D
  requests sent to dead C: 50
--- plus passive ejection
  t=21 client ejects C after 3 fails
  t=35 registry evicts C
  requests sent to dead C: 3

খোঁজা — client-side বনাম server-side

DNS-ভিত্তিক discovery. সবচেয়ে পুরোনো registry হলো DNS (Computer Networks-এর DNS পর্ব)। একটি নামের জন্য কয়েকটি A record, বা host আর port দুটিই জানাতে SRV record. সুবিধা: সব ভাষা আর সব যন্ত্র DNS বোঝে। দুর্বলতা: অনেক resolver, OS বা runtime উত্তর নিজের মতো বেশিক্ষণ cache করে (সংস্করণভেদে আলাদা), তাই মৃত ঠিকানা থেকে যায়; আর সাধারণ DNS জানে না কোন instance অসুস্থ। লেখার সময়ের ডকুমেন্টেশন অনুযায়ী Consul-এর মতো কিছু registry তাই health check-এ পাশ করা instance-গুলোই DNS উত্তরে দেয়।

Kubernetes-ধাঁচের Service. লেখার সময়ের Kubernetes ডকুমেন্টেশন অনুযায়ী, একটি Service object একদল pod-কে একটি স্থির নাম আর একটি স্থির virtual IP (ClusterIP) দেয়। ক্লাস্টারের DNS নামটিকে সেই IP-তে মেলায়, আর প্রতিটি node-এ kube-proxy (বা eBPF-ভিত্তিক বিকল্প) ওই IP-র সংযোগ readiness-এ পাশ করা কোনো একটি pod-এ পাঠায়। অর্থাৎ নিবন্ধন করে platform, আর খোঁজা server-side-এর মতো — “router” প্রতিটি node-এ ছড়ানো। “Headless” Service (ClusterIP ছাড়া) DNS-এ সরাসরি pod-গুলোর IP দেয়, যাতে client নিজে বাছতে পারে। বিস্তারিত network-দিক: Cloud আর container নেটওয়ার্কিং.

# every pod labelled app=payment that passes readiness joins this Service
apiVersion: v1
kind: Service
metadata:
  name: payment            # callers use http://payment (or payment.shop.svc...)
  namespace: shop
spec:
  selector:
    app: payment
  ports:
    - port: 80             # port on the stable virtual IP
      targetPort: 8080     # port the container really listens on
# clusterIP: None  -> "headless": DNS returns the pod IPs, client picks

৮ · Service mesh — sidecar, data plane আর control plane

সেবা যত বাড়ে, প্রতিটির কোডে একই কাজ ফিরে আসে: কাকে ডাকব (discovery), কতক্ষণ অপেক্ষা (timeout), আবার চেষ্টা (retry), এনক্রিপশন আর পরিচয় যাচাই (mTLS), আর প্রতিটি call-এর latency, error ও trace মাপা। পাঁচ ভাষার বিশটি সেবায় এগুলো পাঁচ রকম লাইব্রেরিতে লেখা মানে ভুল আর অমিলের কারখানা।

Service mesh-এর উত্তর: এই কাজগুলো সেবার কোড থেকে বের করে প্রতিটি instance-এর পাশে একটি ছোট proxy-তে দেওয়া — sidecar, যা একই pod বা host-এ চলে। সেবা ভাবে সে সাধারণ HTTP-তে localhost-এ কথা বলছে; বাইরে যাওয়া আর ভেতরে আসা সব traffic network-স্তরের নিয়মে (যেমন iptables) sidecar-এর মধ্য দিয়ে ঘোরানো হয়। Lyft-এ শুরু হয়ে ২০১৬ সালে open-source হওয়া Envoy এমন proxy-র সবচেয়ে পরিচিত উদাহরণ; Istio আর Linkerd পরিচিত open-source mesh (Linkerd নিজের আলাদা proxy ব্যবহার করে)।

• Data plane: সব sidecar মিলে — যারা আসল অনুরোধ বহন করে, নিয়ম মানে আর মাপ নেয়।
• Control plane: কেন্দ্রীয় অংশ, যা sidecar-দের পাঠায় instance-তালিকা, route, timeout-retry-র নিয়ম আর সেবা-পরিচয়ের certificate (Envoy এগুলো পায় xDS নামের একদল API দিয়ে)। সে নিজে অনুরোধ বহন করে না; কিছুক্ষণ বিকল থাকলেও sidecar-রা শেষ জানা config-এ চলে, শুধু নতুন বদল আসে না।

অর্ডার সেবা পেমেন্ট সেবাকে টাকা কাটতে বলছে — ধাপে ধাপে দেখুন।

Mesh যা দেয়, আর যা নেয়

একটি হিসাব (ধরা যাক, সংখ্যাগুলো উদাহরণ মাত্র): একটি পাতায় ৮টি ভেতরের call পরপর, প্রতিটি দুটি sidecar পেরোয়, প্রতি sidecar ০.৫ ms — বাড়তি latency ৮ × ২ × ০.৫ = ৮ ms. ২০০টি pod-এ প্রতি sidecar ৫০ MB memory নিলে মোট ১০ GB, শুধু proxy-র জন্য। বড় সিস্টেমে এই দাম প্রায়ই পোষায়; কয়েকটি সেবার ছোট সিস্টেমে প্রায়ই না।

সাম্প্রতিক কিছু mesh প্রতি pod-এর sidecar-এর বদলে প্রতি node-এ একটি ভাগ করা proxy বা eBPF-এর মতো kernel-স্তরের কৌশল ব্যবহার করে, আর gRPC-র মতো কিছু লাইব্রেরি নিজেই xDS বুঝে proxy ছাড়াই mesh-এ যোগ দিতে পারে — বিবরণ দ্রুত বদলায়, তাই সংস্করণের ডকুমেন্টেশন দেখুন। ভিত্তি একই: data plane বহন করে, control plane নিয়ম দেয়।

৯ · আলাদা deploy-এর নিরাপত্তা-জাল আর সিদ্ধান্ত — versioning, contract test, কখন কোনটি

API versioning আর contract test

আলাদা deploy মানে যেকোনো মুহূর্তে একটি সেবার পুরোনো আর নতুন সংস্করণ একসাথে চলছে, তার client-রাও নানা সংস্করণে। তাই প্রতিটি পরিবর্তনকে backward compatible রাখতে হয় (পর্ব ৮, পর্ব ১২):

• যোগ নিরাপদ, মোছা বা নাম বদলানো বিপজ্জনক — পুরোনো field রাখুন যতদিন কেউ পড়ে।
• Client হোক tolerant reader: অচেনা field উপেক্ষা করে, শুধু দরকারিগুলো পড়ে।
• ভাঙতেই হলে নতুন সংস্করণ (API versioning — /v2 বা header), কিছুদিন দুটিই চালু, ব্যবহার মেপে তারপর পুরোনোটি বন্ধ — expand–contract.

কিন্তু “কেউ এই field পড়ে কি না” জানবেন কীভাবে? এখানে আসে consumer-driven contract. Ian Robinson-এর ২০০৬ সালের একটি প্রবন্ধে বর্ণিত ধারণাটি সহজ: প্রতিটি consumer (যে সেবা ডাকে) একটি চুক্তি লেখে — “আমি এই অনুরোধ পাঠাই, আর উত্তরে এই field-গুলো পড়ি।” Provider-এর (যে সেবা উত্তর দেয়) build-এ সব consumer-এর চুক্তি চালানো হয়; কোনোটি ভাঙলে deploy আটকায়, আসল ব্যবহারকারী টের পাওয়ার আগেই। Pact-এর মতো open-source টুল এ কাজে প্রচলিত। বিশটি সেবা একসাথে চালানো end-to-end পরীক্ষার চেয়ে এটি দ্রুত আর কম ভঙ্গুর, যদিও অল্প কিছু end-to-end পরীক্ষা থাকা তবু ভালো।

কখন কোনটি — ইন্টারভিউতে সিদ্ধান্ত নেওয়া

ইন্টারভিউতে “microservices দিয়ে বানাব” দিয়ে শুরু করা দুর্বল; প্রশ্নকর্তা শুনতে চান কেন. ধারা: requirement (পর্ব ২), তারপর সীমানা, তারপর deploy-এর একক।

ইন্টারভিউতে একটি নমুনা উত্তর: “শুরুতে একটি modular monolith — অর্ডার, ক্যাটালগ আর ব্যবহারকারী আলাদা module ও schema-সহ। দুটি অংশ আলাদা সেবা: মিডিয়া প্রসেসিং, কারণ তার CPU-চাহিদা খুব আলাদা আর কাজটি async; আর পেমেন্ট, কারণ তার নিরাপত্তার ঘের আলাদা। পড়ায় sync, ঘটনায় event; সামনে একটি gateway.” তারপর failure mode: পেমেন্ট ধীর হলে কী হবে? Case study পর্বগুলোতে (৫৪–৬১) এই ধরনের ব্যাখ্যা বারবার লাগবে।

১০ · AI-এর যুগে — architecture-এর পরামর্শ যাচাই

“একটি food delivery অ্যাপের architecture চাই” — এমন প্রশ্নে AI প্রায়ই চকচকে তালিকা দেয়: বারোটি microservice, Kafka, Redis, Kubernetes, service mesh. প্রশ্নই করে না — দল কয়জনের? ব্যবহারকারী কত? কোন call critical path-এ? তিনজনের দলের জন্য এটি সমাধান নয়, বোঝা।

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

• প্রতিটি সেবার একটি মালিক-দল আর প্রতিটি টেবিলের একটি লেখক-সেবা আছে
• Critical path-এর availability (a^N) আর latency (যোগফল বা সবচেয়ে ধীর) নিজে হিসাব করেছি
• একটি সাধারণ feature বদলাতে কয়টি সেবা ছুঁতে হয় গুনেছি, আর সরলতম যে নকশা requirement মেটায় তার সাথে তুলনা করেছি
• প্রতিটি সেবা বিকল বা ধীর হলে কী হবে, timeout আর fallback কী — একটি failure-mode তালিকা লিখেছি
• Mesh, Kafka বা registry-র সীমা আর latency অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি, বা ছোট simulation বা load test চালিয়েছি