Pub/sub আর event-driven architecture — fan-out, choreography বনাম orchestration

১ · একজন বলে, অনেকে শোনে — pub/sub বনাম point-to-point

পর্ব ৩১-এ (message queue) একটি সারি দেখেছেন: কেউ কাজ জমা দেয়, আর কয়েকজন কর্মীর একজন সেটি তুলে নেয়। ব্যাংকের টোকেন-ব্যবস্থার মতো — একটি টোকেন একজন ক্যাশিয়ারই ডাকেন, দুজন নয়। এই ধরনের নাম point-to-point: প্রতিটি বার্তা ঠিক একজন গ্রাহকের কাছে যায়, আর কয়েকজন কর্মী মিলে ভার ভাগ করে (competing consumers).

এবার অন্য প্রশ্ন। একটি অনলাইন বাস-টিকিট সেবায় (কাল্পনিক) রুমানা টিকিট কিনলেন। এই একটি ঘটনার খবর অনেকের দরকার:

• SMS সার্ভিস — রুমানাকে টিকিট নম্বর পাঠাবে;
• Loyalty সার্ভিস — পয়েন্ট যোগ করবে;
• Analytics — ঈদের ভিড়ের ড্যাশবোর্ড হালনাগাদ করবে;
• আর আগামী মাসে হয়তো একটি fraud-check সার্ভিস, যার কথা আজ কেউ জানেই না।

Booking সার্ভিস যদি নিজে এদের একে একে ডাকে, তাহলে তাকে সবার ঠিকানা জানতে হয়, কেউ ধীর হলে সে-ও ধীর হয়, আর নতুন গ্রাহক এলে Booking-এর কোডই বদলাতে হয়। সেবাগুলো আলাদা দলের আলাদা microservice হলে (পর্ব ৪৭) এই বাঁধন আরও ভারী। সমাধান publish/subscribe: Booking শুধু একটি topic-এ (নামওয়ালা চ্যানেল) ঘোষণা দেয়, “টিকিট বুক হয়েছে”; যে শুনতে চায়, সে নিজের একটি subscription খোলে। Publisher জানে না কে শুনছে; প্রতিটি subscriber পায় নিজের কপি।

Topic, subscription আর fan-out

সবচেয়ে গুরুত্বপূর্ণ নিয়মটি হলো: প্রতিটি subscription একটি স্বাধীন গ্রাহক। একটি topic-এ তিনটি subscription থাকলে প্রতিটি event-এর তিনটি delivery হয় — এটিই বার্তার fan-out. আর একটি subscription-এর ভেতরে কয়েকটি কর্মী থাকলে তারা point-to-point-এর মতো ভার ভাগ করে। অর্থাৎ বাস্তবের বেশিরভাগ ব্যবস্থা দুই ধারণা মেশায়: subscription-গুলোর মধ্যে pub/sub, একটি subscription-এর ভেতরে competing consumers. Log-ভিত্তিক broker-এ একই ধারণার নাম consumer group (পর্ব ৩৩, log-ভিত্তিক streaming).

২ · Push বনাম pull, আর কে কোন বার্তা পাবে — filter

Push subscription

Push subscription-এ broker নিজে প্রতিটি বার্তা subscriber-এর একটি HTTP endpoint-এ পাঠায়; 2xx উত্তর মানে ack, অন্য কিছু বা timeout মানে পরে আবার চেষ্টা। সুবিধা: subscriber-কে সারাক্ষণ জিজ্ঞেস করতে হয় না, দেরি কম, serverless function-এর মতো “ডাকলে জাগে” সেবার জন্য সহজ। অসুবিধা: গতি ঠিক করে broker, তাই subscriber ধীর হলে broker-কে হার কমাতে হয়; আর endpoint-টি broker-এর নাগালে খোলা রেখে প্রতিটি অনুরোধ যাচাই করতে হয় (অংশ ৮-এর webhook-এর মতো)।

Pull subscription

Pull subscription-এ subscriber নিজে broker-কে বলে, “আমাকে সর্বোচ্চ ১০০টি দিন।” সুবিধা: গতি subscriber-এর হাতে — যতটা পারে ততটা টানে, তাই backpressure স্বাভাবিকভাবেই থাকে (পর্ব ১৮); batch-এ নিলে প্রতি বার্তার খরচ কমে। অসুবিধা: খালি সময়ে বারবার জিজ্ঞেস করার অপচয় — তাই long polling-এর মতো “কিছু না এলে কিছুক্ষণ ধরে রাখুন” কৌশল; আর batch ভরার অপেক্ষায় কিছু দেরি। Kafka-র consumer pull করে; Google Cloud Pub/Sub দুটোই দেয়।

Filter — topic hierarchy আর attribute

সব subscriber সব event চায় না। দুটি প্রচলিত উপায়:

• Topic hierarchy: topic-এর নাম ডট দিয়ে স্তরে ভাগ — booking.created, booking.cancelled, booking.seat.held; subscription একটি pattern দেয়। RabbitMQ-র topic exchange-এ * মানে ঠিক একটি শব্দ, # মানে শূন্য বা তার বেশি শব্দ; MQTT-তে একই কাজ + আর #, NATS-এ * আর > — চিহ্ন আর খুঁটিনাটি পণ্যভেদে আলাদা।
• Attribute filter: event-এর সাথে কয়েকটি key-value attribute (যেমন channel=app, route=dhaka-rajshahi); subscription বলে, “শুধু channel=app হলে দিন।” Google Cloud Pub/Sub-এর subscription filter আর AWS SNS-এর filter policy এই ধাঁচের; কী কী শর্ত লেখা যায় (সমান, prefix, সংখ্যার পরিসর) আর কতগুলো — লেখার সময়ে পণ্যভেদে আলাদা, ডকুমেন্টেশন দেখে নিন।

Filter broker-এ চললে লাভ: যে বার্তা কেউ চায় না, তা network-এ যায়ই না। Subscriber নিজে ফেলে দিলে কাজ হয়, কিন্তু প্রতিটি বার্তার bandwidth আর প্রক্রিয়ার খরচ দিতে হয়। সাবধানতা: filter সাধারণত শুধু attribute বা topic-এর নাম দেখে, payload-এর গভীরে নয় — তাই কোন তথ্য attribute-এ যাবে, তা event নকশার অংশ।

নিচের simulator একটি ছোট in-memory broker. তিনটি subscription, প্রতিটির নিজের queue: sms চায় booking.*, loyalty চায় শুধু app থেকে আসা booking.created, analytics চায় সব (#). পাঁচটি event publish করে দেখা যাক কে কী পায়:

// In-memory pub/sub broker: topic patterns (* = one word, # = any words) + attribute filters.
function topicMatch(pattern, topic) {          // e.g. "booking.*" matches "booking.created"
  const p = pattern.split("."), t = topic.split(".");
  const go = (i, j) => {
    if (i === p.length) return j === t.length;
    if (p[i] === "#") return go(i + 1, j) || (j < t.length && go(i, j + 1));
    return j < t.length && (p[i] === "*" || p[i] === t[j]) && go(i + 1, j + 1);
  };
  return go(0, 0);
}
const subs = [                                   // each subscription has its OWN queue
  { name: "sms",       pattern: "booking.*",       filter: {} },
  { name: "loyalty",   pattern: "booking.created", filter: { channel: "app" } },
  { name: "analytics", pattern: "#",               filter: {} },
].map((s) => ({ ...s, queue: [] }));
function publish(topic, attrs, id) {
  const got = [];
  for (const s of subs) {
    const ok = topicMatch(s.pattern, topic) &&
      Object.entries(s.filter).every(([k, v]) => attrs[k] === v);
    if (ok) { s.queue.push(id); got.push(s.name); }
  }
  console.log(id.padEnd(5) + topic.padEnd(18) + JSON.stringify(attrs).padEnd(30) +
    "-> " + (got.join(", ") || "(nobody)"));
}
publish("booking.created",   { channel: "app" },          "e1");
publish("booking.created",   { channel: "web" },          "e2");
publish("booking.cancelled", { channel: "app" },          "e3");
publish("payment.failed",    { channel: "app" },          "e4");
publish("booking.seat.held", { channel: "app" },          "e5");
console.log("--- queues after 5 publishes ---");
for (const s of subs) console.log(s.name.padEnd(10) + s.queue.length + "  [" + s.queue.join(" ") + "]");
const total = subs.reduce((a, s) => a + s.queue.length, 0);
console.log("published 5, delivered " + total + " copies");

e1   booking.created   {"channel":"app"}             -> sms, loyalty, analytics
e2   booking.created   {"channel":"web"}             -> sms, analytics
e3   booking.cancelled {"channel":"app"}             -> sms, analytics
e4   payment.failed    {"channel":"app"}             -> analytics
e5   booking.seat.held {"channel":"app"}             -> analytics
--- queues after 5 publishes ---
sms       3  [e1 e2 e3]
loyalty   1  [e1]
analytics 5  [e1 e2 e3 e4 e5]
published 5, delivered 9 copies

৩ · Event-driven architecture — event, command আর query

Event-driven architecture (EDA) মানে এমন নকশা, যেখানে সেবাগুলো একে অপরকে সরাসরি ডাকার বদলে মূলত ঘটনার খবর প্রকাশ করে আর অন্যের খবর শুনে নিজের কাজ করে। এর আগে তিন ধরনের বার্তা আলাদা করে চেনা দরকার, কারণ গুলিয়ে ফেলাই বেশিরভাগ ভুলের শুরু:

একটি সহজ পরীক্ষা: বার্তাটি কি প্রাপককে কিছু করতে বলছে? তাহলে command, event-এর ছদ্মবেশে পাঠালেও। SendSmsRequested নামের “event” আসলে SMS সার্ভিসকে দেওয়া হুকুম — একে point-to-point queue-তে command হিসেবে পাঠানোই সৎ নকশা। Event-এ প্রকাশক শুধু নিজের জগতের সত্য জানায়; কে কী করবে, সেটি শ্রোতার ব্যাপার। Query সাধারণত বার্তায় যায় না; event থেকে বানানো স্থানীয় কপি দিয়েই অনেক সময় query-র দরকার কমানো যায় (নিচে)।

Event দিয়ে কী পাঠাবেন — Fowler-এর তিন ধরন

Martin Fowler ২০১৭ সালের একটি লেখায় (“What do you mean by ‘Event-Driven’?”) দেখান, “event-driven” বলতে মানুষ অন্তত চারটি আলাদা ধাঁচ বোঝান — event notification, event-carried state transfer, event sourcing আর CQRS; এখানে প্রথম তিনটি, কারণ নকশার সিদ্ধান্তে এরাই সরাসরি আসে। এই নামগুলো একটি প্রচলিত শ্রেণিবিভাগ, কোনো মানক নয়; বই আর দলভেদে সীমারেখা একটু আলাদা।

মাঝামাঝি পথও প্রচলিত: event-এ id আর শ্রোতাদের বেশিরভাগের যা লাগে (দাম, রুট), কিন্তু ব্যক্তিগত বা বড় তথ্য নয় — দরকার হলে শ্রোতা অনুমতিসহ আলাদা API-তে চায়। বাইরের প্রতিষ্ঠানে যাওয়া webhook-এ প্রায়ই হালকা event পাঠানো হয়, যাতে গ্রাহক সর্বশেষ অবস্থা নিজে এনে নেয় (অংশ ৮)।

৪ · একটি ভালো event — নাম, id, সময়, envelope আর version

Event একবার প্রকাশ হলে তা অনেকের চুক্তি — কে কোথায় কোন field পড়ছে, প্রকাশক জানেও না। তাই event-কে একটি public API-র মতো যত্নে নকশা করুন।

• অতীত কালে, ব্যবসার ভাষায় নাম: TicketBooked, PaymentRefunded — “কী ঘটেছে”। BookingTableRowUpdated নয় (ডেটাবেসের ভাষা), SendSms নয় (হুকুম)।
• অনন্য event id: প্রতিটি event-এর একটি UUID বা সমতুল্য id. Broker at-least-once দিলে একই event দুবার আসবে; শ্রোতা এই id দেখেই দ্বিতীয় কপি চেনে (পর্ব ৩৪)।
• ঘটনার সময় আর প্রকাশের সময় আলাদা: time — ঘটনা কখন ঘটেছে (UTC, ISO 8601). Event দেরিতে বা উল্টো ক্রমে আসতে পারে; ঘড়িও পুরোপুরি মেলে না (পর্ব ৩৯)।
• উৎস আর subject: কে প্রকাশ করেছে (source), কোন entity নিয়ে (subject, যেমন booking/B42). একই entity-র event-এর ক্রম চাইলে এটিই ordering key বা partition key হয় (পর্ব ৩৩)।
• Type আর schema version: type আর dataschema বা version; schema বদলানোর নিয়ম — নতুন field যোগ ঠিক আছে, পুরোনো field-এর অর্থ বদলানো নয় — পর্ব ১২-এর schema evolution. শ্রোতারা tolerant reader হোক: অচেনা field উপেক্ষা করুক।
• সুতো: correlation id — একটি ব্যবসায়িক প্রবাহের সব বার্তায় একই (যেমন অর্ডার ৪২); causation id — কোন বার্তার ফলে এটি তৈরি হলো। এ দুটিই পরে debugging-এর ভরসা (অংশ ৭)।

এই সাধারণ field-গুলোকে বলে envelope: খামের ওপর প্রেরক, প্রাপক আর তারিখ, ভেতরে চিঠি। ডাকঘরের বাছাইকারী খাম পড়েই চিঠি ঠিক থলেতে দেন, চিঠি খোলেন না — broker আর filter-ও তেমনি envelope বা attribute দেখে। CNCF-এর CloudEvents specification (সংস্করণ ১.০, ২০১৯) এমন একটি মানক envelope দেয়, যার বাধ্যতামূলক field id, source, specversion আর type; বাকিগুলো ঐচ্ছিক বা extension. নিচে সেই ধাঁচে একটি event:

{
  "specversion": "1.0",
  "id": "0b7c4e9a-6d1f-4a37-9a7e-2f5c8d1e3b40",
  "source": "/booking-service",
  "type": "com.example.booking.ticket.booked.v2",
  "subject": "booking/B42",
  "time": "2026-10-28T14:05:09Z",
  "datacontenttype": "application/json",
  "correlationid": "order-42",
  "causationid": "evt-payment-charged-9f21",
  "data": {
    "bookingId": "B42",
    "trip": 7,
    "route": "dhaka-rajshahi",
    "seat": "A3",
    "amountPaisa": 85000,
    "channel": "app"
  }
}

লক্ষ করুন: টাকার পরিমাণ পয়সায় পূর্ণসংখ্যা (amountPaisa), দশমিক নয় (পর্ব ১২); যাত্রীর ফোন নম্বর event-এ নেই — যার দরকার (SMS সার্ভিস), সে অনুমতিসহ আলাদা জায়গা থেকে নেবে। correlationid আর causationid CloudEvents-এর মূল field নয়, extension হিসেবে যোগ করা — নামকরণ দলভেদে আলাদা।

৫ · একটি event, অনেক সেবা — fan-out-এর পথ আর খরচ

এবার রুমানার একটি event কীভাবে তিন সেবায় পৌঁছায়, ধাপে ধাপে। SMS push subscription-এ, loyalty আর analytics pull-এ; analytics ঠিক তখন deploy-এর জন্য ৪০ সেকেন্ড বন্ধ, আর সেই সময়ে সেকেন্ডে প্রায় ৩০টি নতুন event আসছে (ধরা যাক)। “পরে” চাপুন:

Fan-out-এর হিসাব — একটি event × N subscriber

ধরা যাক publisher সেকেন্ডে E-টি event প্রকাশ করে, প্রতিটির আকার s, আর N-টি subscription সব event চায়। তাহলে:

• Delivery: সেকেন্ডে E × N. Publish-এর খরচ N-এর ওপর নির্ভর করে না, delivery-রটা করে — তাই subscription বাড়লে চাপ পড়ে broker-এর বাইরে যাওয়ার পথে।
• বাইরে যাওয়া bandwidth: E × N × s. ২,০০০ event/s, ১ KB, ১০টি subscription → ২০,০০০ × ১ KB = সেকেন্ডে ২০ MB.
• জমা থাকা কপি: queue-per-subscription ধাঁচে প্রতিটি subscription-এর নিজের কপি — কেউ পিছিয়ে পড়লে N গুণ পর্যন্ত জায়গা। Log-ভিত্তিক broker একটি কপি রাখে, আর প্রতিটি গ্রাহক শুধু নিজের অবস্থান (offset) মনে রাখে (পর্ব ৩৩)।
• প্রকাশকের availability: সরাসরি ডাকলে তিনটি ৯৯.৯% সেবার সবাইকে লাগলে ০.৯৯৯^৩ ≈ ৯৯.৭০%; pub/sub-এ publish-এর জন্য শুধু broker লাগে, subscriber-দের availability আর গুণ হয় না। তবে প্রতিটি event-এর কোনো না কোনো subscriber-এ সমস্যার সম্ভাবনা ১ − p^N: p = ০.৯৯৯, N = ১০ হলে প্রায় ১% (০.৯৯৫৫%) — সেকেন্ডে ২,০০০ event-এ প্রতি সেকেন্ডে প্রায় ২০টি event-এর কোথাও retry লাগবে। তাই প্রতিটি subscription-এর নিজের retry, DLQ আর monitoring চাই।

একটি event থেকে লাখো ব্যবহারকারীর কাছে push, SMS আর email পৌঁছানোর পুরো নকশা — যেখানে fan-out-এর এই হিসাব সবচেয়ে বড় ভূমিকা নেয় — পর্ব ৫৭-এর notification system case study-তে আসবে।

নিচের calculator push আর pull-এর request ও দেরিও দেখায়। সরল মডেল (সব মান ধরে নেওয়া): push প্রতি বার্তায় একটি request; pull একবারে সর্বোচ্চ ১০০টি বার্তা টানে, আর একটি pull শেষ হয় batch ভরলে বা ১ সেকেন্ড অপেক্ষার পর — Kafka-র মতো broker-এর “কমপক্ষে এত byte, সর্বোচ্চ এত অপেক্ষা” ধরনের setting-এর মতো। RTT ২ ms.

// Fan-out cost model: E events/s, N subscriptions, payload KB. All inputs are ASSUMED values.
const KB = 1, RTT = 2;                 // payload size (KB), broker-subscriber round trip (ms)
const BATCH = 100, WAIT = 1000;        // pull: up to BATCH msgs per call, long-poll waits at most WAIT ms
function row(E, N) {
  const deliveries = E * N;                          // every subscription gets its own copy
  const egressMBs = deliveries * KB / 1000;          // MB/s leaving the broker
  const pushReq = deliveries;                        // push: one HTTP request per message
  const callMs = Math.min(BATCH / E * 1000, WAIT);   // pull: a call ends when the batch fills or WAIT ends
  const pullReq = N * 1000 / callMs;                 // pull calls per second, all subscriptions
  const pushLat = RTT / 2;                           // push: message leaves as soon as it arrives
  const pullLat = callMs / 2 + RTT / 2;              // pull: on average waits half a call
  return [E, N, deliveries, egressMBs.toFixed(1), pushReq, pullReq.toFixed(0),
          pushLat.toFixed(0) + " ms", pullLat.toFixed(0) + " ms"];
}
const head = ["events/s", "subs", "deliv/s", "MB/s out", "push req/s", "pull req/s", "push +lat", "pull +lat"];
const show = (r) => console.log(r.map((x) => String(x).padStart(11)).join(""));
show(head);
for (const [E, N] of [[2000, 1], [2000, 3], [2000, 10], [2000, 50], [5, 10]]) show(row(E, N));
// storage: queue-per-subscription keeps N copies; a shared log keeps 1 copy + N offsets (see lesson 33)
const E = 2000, N = 10, hours = 24, perDayGB = E * KB * 3600 * hours / 1e6;
console.log("1-day backlog at " + E + " ev/s: shared log " + perDayGB.toFixed(1) + " GB, " +
  N + " queues " + (perDayGB * N).toFixed(1) + " GB");

   events/s       subs    deliv/s   MB/s out push req/s pull req/s  push +lat  pull +lat
       2000          1       2000        2.0       2000         20       1 ms      26 ms
       2000          3       6000        6.0       6000         60       1 ms      26 ms
       2000         10      20000       20.0      20000        200       1 ms      26 ms
       2000         50     100000      100.0     100000       1000       1 ms      26 ms
          5         10         50        0.1         50         10       1 ms     501 ms
1-day backlog at 2000 ev/s: shared log 172.8 GB, 10 queues 1728.0 GB

৬ · Choreography বনাম orchestration — একই প্রবাহ, দুই নকশা

পর্ব ২৫-এ (saga) দুই ধাঁচের পরিচয় পেয়েছেন। এবার একটি প্রবাহ দুইভাবে চালিয়ে পাশাপাশি দেখা যাক। রুমানার অর্ডার ৪২: সিট hold → টাকা কাটা → অপারেটরের টিকিট; তৃতীয় ধাপে অপারেটর জানায় “ট্রিপ বাতিল” — তাই টাকা ফেরত আর সিট ছাড়া।

Choreography — কেন্দ্রহীন event-শিকল

Choreography-তে প্রতিটি সেবা জানে কোন event শুনে কী করবে আর তারপর কোন event প্রকাশ করবে। নিচে event bus-এর log আর প্রতিটি সেবার অবস্থা:

Orchestration — একজন পরিচালক

Orchestration-এ একটি orchestrator (বা workflow engine, পর্ব ৩৭ — background job আর workflow engine) নিজের ডেটাবেসে প্রবাহের একটি সারি রাখে, প্রতিটি সেবাকে command পাঠায় আর উত্তর লিখে রাখে:

এবার দুই নকশা কোডে, একই ব্যর্থতাসহ। প্রতিটি অংশ কোন বার্তা দেখেছে, তা আলাদা করে গোনা হচ্ছে — কে কতটা জানে, তার মাপ:

// Order 42: HoldSeat -> Charge -> IssueTicket (FAILS: trip cancelled) -> compensate. Two styles.
const seen = {};                                  // component -> messages it has received
const recv = (who, msg) => (seen[who] = seen[who] || []).push(msg);
const log = (n, s) => console.log(String(n).padStart(2) + " " + s);
console.log("== CHOREOGRAPHY: services react to events, nobody is in charge");
const react = {                                   // event -> [subscriber, event it publishes next]
  OrderPlaced: ["seat", "SeatHeld"],         SeatHeld: ["payment", "PaymentCharged"],
  PaymentCharged: ["ticket", "TicketFailed"], TicketFailed: ["payment", "PaymentRefunded"],
  PaymentRefunded: ["seat", "SeatReleased"], SeatReleased: ["order", null],
};
let ev = "OrderPlaced", n = 0;
while (ev) {
  const [svc, next] = react[ev];
  recv(svc, ev); log(++n, ev.padEnd(16) + "-> " + svc + (next ? " publishes " + next : " marks CANCELLED"));
  ev = next;
}
for (const c of ["order", "seat", "payment", "ticket"]) console.log("   " + c.padEnd(8) + "saw: " + seen[c].join(", "));
for (const k in seen) delete seen[k];
console.log("== ORCHESTRATION: one orchestrator sends commands and records every reply");
const plan = [["seat", "HoldSeat", "ReleaseSeat"], ["payment", "Charge", "Refund"], ["ticket", "IssueTicket", null]];
const done = []; n = 0;
for (const [svc, cmd, undo] of plan) {
  const ok = cmd !== "IssueTicket";
  recv(svc, cmd); recv("orchestrator", svc + ":" + (ok ? "OK" : "FAILED"));
  log(++n, ("cmd " + cmd).padEnd(16) + "-> " + svc); log(++n, "reply " + (ok ? "OK" : "FAILED").padEnd(10) + "<- " + svc);
  if (!ok) { for (const [s, , u] of done.reverse()) {
      recv(s, u); recv("orchestrator", s + ":" + u + " OK");
      log(++n, ("cmd " + u).padEnd(16) + "-> " + s); log(++n, "reply OK".padEnd(16) + "<- " + s); }
    break; }
  done.push([svc, cmd, undo]);
}
for (const c of ["orchestrator", "seat", "payment", "ticket"]) console.log("   " + c.padEnd(13) + "saw: " + seen[c].join(", "));

== CHOREOGRAPHY: services react to events, nobody is in charge
 1 OrderPlaced     -> seat publishes SeatHeld
 2 SeatHeld        -> payment publishes PaymentCharged
 3 PaymentCharged  -> ticket publishes TicketFailed
 4 TicketFailed    -> payment publishes PaymentRefunded
 5 PaymentRefunded -> seat publishes SeatReleased
 6 SeatReleased    -> order marks CANCELLED
   order   saw: SeatReleased
   seat    saw: OrderPlaced, PaymentRefunded
   payment saw: SeatHeld, TicketFailed
   ticket  saw: PaymentCharged
== ORCHESTRATION: one orchestrator sends commands and records every reply
 1 cmd HoldSeat    -> seat
 2 reply OK        <- seat
 3 cmd Charge      -> payment
 4 reply OK        <- payment
 5 cmd IssueTicket -> ticket
 6 reply FAILED    <- ticket
 7 cmd Refund      -> payment
 8 reply OK        <- payment
 9 cmd ReleaseSeat -> seat
10 reply OK        <- seat
   orchestrator saw: seat:OK, payment:OK, ticket:FAILED, payment:Refund OK, seat:ReleaseSeat OK
   seat         saw: HoldSeat, ReleaseSeat
   payment      saw: Charge, Refund
   ticket       saw: IssueTicket

পাশাপাশি তুলনা

বাস্তবে প্রায়ই মিশ্র পথ: একটি দলের সীমানার ভেতরের জটিল প্রবাহ (টাকা আর compensation-সহ বুকিং) orchestration-এ, আর সীমানা পেরিয়ে অন্য দলকে খবর দেওয়া (TicketBooked → loyalty, analytics, notification) choreography-তে। নিয়ম মনে রাখুন: যে প্রবাহের একজন ব্যবসায়িক মালিক আছেন আর যার শেষ অবস্থা কাউকে জবাবদিহি করতে হয়, তার একটি স্পষ্ট মালিক-কোডও থাকুক। যে খবরের পরে কী হবে তা প্রকাশকের মাথাব্যথা নয়, তা event হয়ে ছড়াক।

৭ · Temporal decoupling-এর দাম — consistency, ক্রম, duplicate আর debugging

Pub/sub-এর বড় উপহার temporal decoupling: প্রকাশক আর শ্রোতাকে একই সময়ে চালু থাকতে হয় না। Analytics ৪০ সেকেন্ড বন্ধ থাকলেও বুকিং চলেছে (অংশ ৫)। কিন্তু সময় আলাদা হওয়া মানে কয়েকটি নতুন দায়:

• Eventual consistency: রুমানা টিকিট কেনার পর loyalty পাতায় পয়েন্ট দেখলেন না — event এখনো প্রক্রিয়া হয়নি। UI-তে “হালনাগাদ হচ্ছে” দেখান, বা যে পাতা সঙ্গে সঙ্গে সঠিক হতেই হবে, তা সরাসরি উৎস থেকে পড়ুন (পর্ব ২২-এর read-your-writes). Event-ভিত্তিক কপি সবসময় “কিছুটা পুরোনো” হতে পারে — নকশায় এটি মেনে নিন, লুকাবেন না।
• ক্রম: BookingCancelled যদি BookingCreated-এর আগে পৌঁছায়? সাধারণত শুধু একই key-র (একই বুকিং) event-এর ক্রম রক্ষা করা যায়, সব event-এর নয় — ordering key বা partition (পর্ব ৩৩)। শ্রোতা version বা sequence number দেখে পুরোনো event উপেক্ষা করতে পারে।
• Duplicate: প্রায় সব নির্ভরযোগ্য broker at-least-once — ack হারালে আবার আসে। প্রতিটি শ্রোতা event id দিয়ে idempotent হোক; বিস্তারিত পর্ব ৩৪-এ (delivery semantics).
• Debugging: সরাসরি ডাকলে একটি stack trace বা একটি HTTP log-এ পুরো পথ দেখা যায়; event-শিকলে কারণ আর ফল আলাদা সেবায়, আলাদা সময়ে। “Payment কেন refund করল?” — উত্তর Ticket-এর log-এ, তিন সেকেন্ড আগে।
• নিঃশব্দ ব্যর্থতা: কোনো শ্রোতা ভুল filter দিয়ে কিছুই পাচ্ছে না, বা একটি subscription মুছে গেছে — প্রকাশক কখনো error দেখবে না। তাই প্রতিটি subscription-এর জমা (backlog), সবচেয়ে পুরোনো না-পড়া বার্তার বয়স আর DLQ-র আকার monitor করুন।

সুতো জোড়া — correlation id আর distributed tracing

উপায় হলো প্রতিটি বার্তায় সুতো রাখা। প্রতিটি event-এ correlation id (পুরো প্রবাহের এক id) আর causation id (কোন বার্তা থেকে জন্ম)। প্রতিটি সেবা log-এ এ দুটি লেখে, আর নিজে নতুন event প্রকাশ করলে correlation id হুবহু কপি করে, causation id-তে নিজের পাওয়া event-এর id বসায়। তাহলে একটি query-তে পুরো গাছ: OrderPlaced → SeatHeld → PaymentCharged → TicketFailed → …. Distributed tracing একই ধারণাকে যন্ত্রে বসায় — trace context (W3C Trace Context-এর traceparent header-এর মতো) বার্তার header বা attribute-এ বয়ে নিয়ে যাওয়া হয়; বিস্তারিত পর্ব ৫০-এ (observability). Asynchronous পথে এই context হাতে বসাতে হয়, অনেক লাইব্রেরি নিজে থেকে করে না — যাচাই করে নিন।

14:05:09.120 order   corr=order-42 id=e-101 cause=-     OrderPlaced published
14:05:09.180 seat    corr=order-42 id=e-102 cause=e-101 SeatHeld A3
14:05:09.410 payment corr=order-42 id=e-103 cause=e-102 PaymentCharged 850
14:05:12.730 ticket  corr=order-42 id=e-104 cause=e-103 TicketFailed: trip cancelled
14:05:12.900 payment corr=order-42 id=e-105 cause=e-104 PaymentRefunded 850
14:05:13.050 seat    corr=order-42 id=e-106 cause=e-105 SeatReleased A3

৮ · Webhook — প্রতিষ্ঠানের সীমানা পেরোনো pub/sub

আপনার বাস-টিকিট সেবা একটি অংশীদার ট্রাভেল এজেন্সিকে (কাল্পনিক) জানাতে চায়, কখন তাদের বিক্রি করা টিকিট বাতিল হলো। তারা আপনার broker-এ subscribe করতে পারে না — ভিন্ন প্রতিষ্ঠান, ভিন্ন network. সমাধান webhook: অংশীদার একটি HTTPS URL নিবন্ধন করে, আর ঘটনা ঘটলে আপনি সেখানে POST করেন। এটি আসলে push subscription, শুধু ইন্টারনেট পেরিয়ে, এমন একজন গ্রাহকের কাছে যার সার্ভার আপনার নিয়ন্ত্রণে নেই। নিরাপত্তা আর নির্ভরযোগ্যতার দায় দুই দিকেই।

প্রদাতা হিসেবে — যা পাঠাবেন

• স্বাক্ষর: প্রতিটি অংশীদারের জন্য আলাদা গোপন চাবি; timestamp + "." + raw body-এর ওপর HMAC-SHA256 হিসাব করে header-এ পাঠান। গ্রাহক একই হিসাব করে মিলিয়ে নেয় — বার্তাটি আপনারই, পথে বদলায়নি। (HMAC-এর ভিত্তি Computer Networks কোর্সের cryptography পর্বে।)
• Timestamp আর event id: স্বাক্ষরে timestamp থাকায় গ্রাহক পুরোনো বার্তা প্রত্যাখ্যান করতে পারে (যেমন ৫ মিনিটের বেশি পুরোনো) — পুরোনো বৈধ বার্তা আবার পাঠানোর (replay) বিরুদ্ধে সুরক্ষা; event id দিয়ে সে duplicate চেনে।
• Retry, backoff আর শেষ সীমা: 2xx না পেলে exponential backoff আর jitter-সহ আবার পাঠান (পর্ব ৪৮) — কয়েক ঘণ্টা বা দিন পর্যন্ত; তারপর DLQ-তে রাখুন, অংশীদারকে জানান, আর বারবার ব্যর্থ endpoint সাময়িকভাবে বন্ধ করুন। প্রতিটি অংশীদারের আলাদা queue, যাতে একজনের ধীর সার্ভার অন্যদের আটকে না দেয়।
• ক্রমের প্রতিশ্রুতি দেবেন না: retry-র কারণে পরের event আগে পৌঁছাতে পারে। হালকা event (“বুকিং B42 বদলেছে”) পাঠিয়ে গ্রাহককে API থেকে সর্বশেষ অবস্থা আনতে বলা প্রায়ই নিরাপদ।
• চাবি বদল আর নিবন্ধিত URL যাচাই: চাবি বদলের সময় কিছুক্ষণ পুরোনো আর নতুন দুই চাবিতে স্বাক্ষর দিন। অংশীদারের দেওয়া URL-এ পাঠানোর সময় শুধু HTTPS, আর আপনার ভেতরের network-এর ঠিকানায় (private IP, metadata ঠিকানা) পাঠানো আটকান — নইলে webhook-ব্যবস্থাই আপনার ভেতরের সেবায় পৌঁছানোর পথ হয়ে যায়।

গ্রাহক হিসেবে — যা যাচাই করবেন

on POST /webhooks/bus-tickets:
    body   = raw request bytes            # verify BEFORE parsing JSON
    ts     = header "X-Timestamp"
    sig    = header "X-Signature"
    if abs(now - ts) > 5 minutes:         reject 400   # stale: possible replay
    expect = HMAC_SHA256(secret, ts + "." + body)
    if not constant_time_equal(expect, sig): reject 401
    event  = parse_json(body)
    in one local transaction:
        if inbox has event.id:             return 200   # duplicate, already handled
        insert event.id into inbox; enqueue event for processing
    return 200 quickly                    # heavy work happens later, from the queue

তিনটি জিনিস লক্ষ করুন। স্বাক্ষর যাচাই হয় কাঁচা byte-এর ওপর — JSON parse করে আবার বানালে space বা ক্রম বদলে স্বাক্ষর মেলে না। তুলনা হয় constant-time-এ। আর ভারী কাজ পরে, queue থেকে — দ্রুত 2xx না দিলে প্রদাতা timeout ধরে আবার পাঠাবে, তাতে duplicate বাড়ে। Header-এর নাম আর স্বাক্ষরের ঠিক বিন্যাস প্রদাতাভেদে আলাদা; তাদের ডকুমেন্টেশন অনুযায়ী মেলান।

৯ · Anti-pattern — যেখানে event-driven নকশা জট পাকায়

Event-driven নকশা শুরুতে হালকা লাগে: “শুধু একটি event প্রকাশ করুন, বাকিরা যা খুশি করুক।” কয়েক বছর পরে তিনটি চেনা anti-pattern দেখা দেয় (নামগুলো প্রচলিত কথ্য নাম, মানক পরিভাষা নয়):

আরও দুটি সতর্কতা। Event দিয়ে request-response: GetPriceRequested event পাঠিয়ে PriceReturned-এর অপেক্ষা — সরাসরি একটি API কলের চেয়ে ধীর, জটিল আর debugging-এ কঠিন; এখানে query-ই ঠিক। সব কিছু event-driven: যে কাজে সঙ্গে সঙ্গে উত্তর লাগে (“এই সিট এখন খালি?”), সেখানে synchronous কল সৎ নকশা। Event-driven একটি যন্ত্র, ধর্ম নয়।

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

“আমার অ্যাপকে event-driven করো” বললে AI প্রায়ই একটি চকচকে ছবি দেয়: “Kafka-তে সব event, প্রতিটি সেবা microservice, Redis cache, CQRS আর event sourcing.” দশজন ব্যবহারকারীর একটি অভ্যন্তরীণ টুলেও। চেনা ভুলগুলো:

AI-এর নকশা মানার আগে — চেকলিস্ট

• প্রতিটি বার্তাকে event, command বা query হিসেবে চিহ্নিত করেছি; event-এর নাম অতীত কালে
• Fan-out (E × N × s) আর জমা কপির জায়গা নিজে হিসাব করেছি, calculator-এ মিলিয়েছি
• প্রতিটি শ্রোতা idempotent; ক্রম কোন key-তে লাগবে, ঠিক করেছি; DLQ আর backlog monitoring আছে
• প্রবাহের মালিক কে, “এখন কোথায়” কে বলবে — choreography বনাম orchestration ভেবে বেছেছি; failure-mode review করেছি
• Event-এ envelope (id, time, source, type, version, correlation id) আছে; ভেতরের ডেটাবেসের সারি ঢালা হয়নি
• পণ্যের সীমা ডকুমেন্টেশনে মিলিয়েছি; webhook-এ স্বাক্ষর, timestamp আর retry যাচাই করেছি