Cloud-এর queue, event bus আর workflow — সার্ভিস জোড়ার ধরন

১ · ফোনে দাঁড়িয়ে থাকা, না স্লিপ রেখে যাওয়া

একটি কাল্পনিক অনলাইন বাজার অ্যাপের কথা ভাবুন। ক্রেতা “অর্ডার করুন” চাপলেন। এরপর পাঁচটি কাজ: stock ধরে রাখা, টাকা কাটা, courier ডাকা, email পাঠানো, আর হিসাবের দলের জন্য তথ্য তোলা। প্রথম সংস্করণে order service পাঁচটি সার্ভিসকে পরপর HTTP দিয়ে ডাকে, আর উত্তরের জন্য দাঁড়িয়ে থাকে। একে বলে synchronous call.

হিসাবটি দেখুন। ধরুন প্রতিটি সার্ভিসের availability ৯৯.৯%. পাঁচটি সবই লাগলে পুরো অর্ডারের availability ০.৯৯৯⁵ ≈ ৯৯.৫%. মানে ৩০ দিনের মাসে প্রায় ৩.৬ ঘণ্টা অর্ডার আটকে থাকতে পারে। আর email সার্ভিস ধীর হলে ক্রেতা ঘুরতে থাকা চাকা দেখেন, যদিও টাকা কাটা ঠিকই হয়েছে। একটি ছোট সার্ভিস পুরো দরজা বন্ধ করে দিল। সার্ভিসগুলো খুব শক্ত করে বাঁধা।

সেই বোর্ডই message queue. পাঠানো পক্ষ বার্তা রেখে চলে যায়, কাজ করা পক্ষ পরে নেয়। এই আলগা জোড়াকে বলে loose coupling. এতে তিনটি লাভ: দুই পক্ষকে একসাথে চালু থাকতে হয় না, ভিড়ের চূড়া সমান হয়ে যায়, আর একটি অংশ পড়লে বাকিটা চলে।

দামও আছে। ক্রেতা তখনই চূড়ান্ত ফল জানেন না, অর্থাৎ eventual consistency. বার্তা দুবার আসতে পারে। ক্রম উল্টাতে পারে। ভুল ধরতে এক জায়গার log যথেষ্ট নয়। তাই সবকিছু queue-তে পাঠানো ঠিক নয়। ক্রেতার তখনই উত্তর দরকার হলে, যেমন “কার্ড গৃহীত হলো কি না”, সরাসরি ডাকাই ঠিক। উত্তর পরে দিলে চলে এমন কাজই queue-তে যায়।

২ · চার আকৃতি — queue, topic, event bus আর stream

Cloud-এর তালিকায় অনেক নাম। কিন্তু আকৃতি মাত্র চারটি। প্রথম প্রশ্নটি সবসময় একই: একটি বার্তা কতজন পাবে, আর কে ঠিক করবে?

মানচিত্রটি মোটা দাগে সত্য, হুবহু নয়। এক সার্ভিস একাধিক ঘরে বসে। Google Pub/Sub একাই topic আর queue-র কাজ করে: topic-এ পাঠানো হয়, আর প্রতিটি subscription ভেতরে queue-র মতো। Service Bus-এ queue আর topic দুটোই আছে। নাম মিলিয়ে নয়, আচরণ মিলিয়ে বাছুন।

বাছাইয়ের ছোট নিয়ম:

• একটি কাজ করিয়ে নিতে হবে (“এই ছবি ছোট করুন”): queue.
• একটি ঘটনা জানাতে হবে, শ্রোতা অনেক (“অর্ডার হয়েছে”): topic, প্রতিটি শ্রোতার সামনে নিজের queue.
• অনেক উৎসের ঘটনা, ভেতরের তথ্য দেখে পথ বাছতে হবে: event bus. Cloud-এর নিজের ঘটনা, যেমন storage-এর event notification, প্রায়ই এখানে আসে।
• বিপুল প্রবাহ, ক্রম লাগবে, আবার পড়তে হবে: stream. চলমান পাঠককে বলে stream consumer. বিস্তারিত তত্ত্ব log-streaming পর্বে.

৩ · একটি বার্তার জীবন — visibility timeout আর at-least-once

সবচেয়ে গুরুত্বপূর্ণ কথাটি প্রথমেই: Queue থেকে বার্তা নিলে সেটি মোছে না। বার্তা শুধু কিছুক্ষণের জন্য অন্যদের চোখের আড়ালে যায়। Worker কাজ শেষ করে আলাদা করে delete পাঠালে তবেই মোছে। এই delete-ই acknowledgement. আড়ালের সময়টিকে বলে visibility timeout.

এই নকশার কারণ সহজ। Worker মাঝপথে মরে গেলে কেউ খবর দেবে না। তাই নীরবতাকেই ব্যর্থতা ধরা হয়। নিচে একটি বার্তার পুরো জীবন দেখুন, যেখানে প্রথম worker মাঝপথে পড়ে যায়।

এই আচরণের নাম at-least-once delivery: বার্তা হারায় না, কিন্তু একাধিকবার আসতে পারে। তিন cloud-এ ব্যবস্থাটি একই, নাম আলাদা:

এবার সেই বিপজ্জনক ঘটনা। Worker মরেনি, শুধু ধীর। নিচের simulator-এ W1-এর কাজে ৪৫ সেকেন্ড লাগে, আর timeout ৩০ সেকেন্ড। তিনটি setting পরপর চলবে:

// One order, one queue, two workers. Simulated clock in seconds, no real waiting.
// W1 is slow (45 s of work). W2 is quick (10 s of work).
function run(visibility, useKey) {
  const msg = { id: "order-101", visibleAt: 0, receives: 0, deleted: false };
  const workers = [{ name: "W1", work: 45, busyUntil: 0 }, { name: "W2", work: 10, busyUntil: 0 }];
  const finishing = [], processed = new Set();
  let charges = 0;
  console.log(`--- visibility ${visibility} s, idempotency key ${useKey ? "ON" : "OFF"} ---`);
  for (let t = 0; t <= 120; t++) {
    for (const job of finishing.filter(j => j.at === t)) {
      if (useKey && processed.has(msg.id)) {
        console.log(`t=${t}  ${job.w}: key already used, skip the charge`);
      } else {
        processed.add(msg.id); charges++;
        console.log(`t=${t}  ${job.w}: CHARGE card (total charges ${charges})`);
      }
      if (!msg.deleted) { msg.deleted = true; console.log(`t=${t}  ${job.w}: delete message`); }
    }
    const free = workers.find(w => w.busyUntil <= t);
    if (!msg.deleted && msg.visibleAt <= t && free) {
      msg.receives++;
      msg.visibleAt = t + visibility;
      free.busyUntil = t + free.work;
      finishing.push({ at: free.busyUntil, w: free.name });
      console.log(`t=${t}  ${free.name}: receive #${msg.receives}, hidden until t=${msg.visibleAt}`);
    }
  }
  console.log(`result: receives=${msg.receives} charges=${charges}\n`);
}
run(30, false);   // timeout shorter than the slow worker
run(30, true);    // same timing, consumer is idempotent
run(60, false);   // timeout longer than the slow worker

--- visibility 30 s, idempotency key OFF ---
t=0  W1: receive #1, hidden until t=30
t=30  W2: receive #2, hidden until t=60
t=40  W2: CHARGE card (total charges 1)
t=40  W2: delete message
t=45  W1: CHARGE card (total charges 2)
result: receives=2 charges=2

--- visibility 30 s, idempotency key ON ---
t=0  W1: receive #1, hidden until t=30
t=30  W2: receive #2, hidden until t=60
t=40  W2: CHARGE card (total charges 1)
t=40  W2: delete message
t=45  W1: key already used, skip the charge
result: receives=2 charges=1

--- visibility 60 s, idempotency key OFF ---
t=0  W1: receive #1, hidden until t=60
t=45  W1: CHARGE card (total charges 1)
t=45  W1: delete message
result: receives=1 charges=1

Timeout বাছার ব্যবহারিক নিয়ম:

• কাজের tail latency-এর চেয়ে বড় রাখুন, গড়ের চেয়ে নয়। p99 ২০ সেকেন্ড হলে ৩০ সেকেন্ড কমই।
• খুব লম্বাও নয়। ১ ঘণ্টা দিলে worker মরলে ১ ঘণ্টা কাজ আটকে থাকে।
• লম্বা কাজে worker মাঝে মাঝে সময় বাড়ায়। একে heartbeat বলে, SQS-এ ChangeMessageVisibility.
• Queue-র পেছনে function থাকলে নিয়ম কড়া: লেখার সময়ে AWS-এর নথি timeout-কে function timeout-এর অন্তত ছয় গুণ রাখতে বলে, কারণ throttling হলেও পুনরায় চেষ্টা হয়। Function-এর আচরণ পর্ব ৬৯-এ।

Idempotency-র আসল রূপ হলো ডেটাবেসের একটি unique নিয়ম। “আগে দেখে নিই, তারপর লিখি” দুই ধাপে করলে দুই worker একসাথে “নেই” দেখতে পারে। তাই চিহ্ন আর ফল এক transaction-এ লিখুন:

-- PostgreSQL. processed_messages.event_id has a UNIQUE constraint.
BEGIN;
INSERT INTO processed_messages (event_id) VALUES ('evt-7f3a')
  ON CONFLICT (event_id) DO NOTHING;
-- 0 rows inserted means a duplicate: ROLLBACK and delete the message.
UPDATE orders SET status = 'PAID' WHERE id = 'order-101';
COMMIT;

টাকা কাটার মতো বাইরের কাজ আপনার transaction-এ ঢোকে না। তখন payment provider-কে idempotency token দিন, আর order id থেকে সেটি বানান, যাতে retry-তে একই token যায়। Idempotency-র পুরো কৌশল, যেমন dedup store-এর মেয়াদ আর inbox pattern, আছে delivery semantics পর্বে.

৪ · Retry, poison message আর dead-letter queue

ব্যর্থতা দুই রকম। সাময়িক: ডেটাবেস ব্যস্ত, network কেঁপেছে। আবার চেষ্টা করলে ঠিক হবে। স্থায়ী: বার্তার JSON ভাঙা, যে অর্ডারের কথা বলছে সেটি নেই। হাজারবার চেষ্টাতেও হবে না। এমন বার্তাকে বলে poison message.

Queue দুটোকে আলাদা করতে পারে না। সে শুধু দেখে delete আসেনি। তাই একটি সীমা লাগে: এতবার নেওয়ার পরেও শেষ না হলে বার্তাকে সরিয়ে আলাদা জায়গায় রাখা হবে। সেই জায়গাই dead-letter queue (DLQ), আর সীমাটি SQS-এ maxReceiveCount. ডাকঘরের “ঠিকানা মেলেনি” তাকের কথা ভাবুন: চিঠি ফেলে দেওয়া হয় না, পিয়নও বারবার ঘোরেন না, কেউ পরে হাতে দেখেন।

{
  "deadLetterTargetArn": "arn:aws:sqs:ap-south-1:123456789012:orders-dlq",
  "maxReceiveCount": 3
}

নিচের simulator-এ তিনটি বার্তা: A সুস্থ, B একবার ব্যর্থ হয় (সাময়িক), C-র JSON ভাঙা (স্থায়ী)। সীমা ৩, timeout ৩০ সেকেন্ড।

// Dead-letter flow. A is healthy, B fails once, C is a poison message.
const VISIBILITY = 30, MAX_RECEIVES = 3, RETENTION = 4 * 24 * 3600;
const msgs = [
  { id: "A", failsFor: 0, why: "" },
  { id: "B", failsFor: 1, why: "db timeout" },
  { id: "C", failsFor: Infinity, why: "bad JSON" },
].map(m => ({ ...m, visibleAt: 0, receives: 0, state: "queue" }));
const dlq = [];

console.log("t(s)  msg  receive  result");
for (let t = 0; t <= 200; t += 10) {
  for (const m of msgs) {
    if (m.state !== "queue" || m.visibleAt > t) continue;
    if (m.receives >= MAX_RECEIVES) {         // limit already used up: redrive policy acts
      m.state = "dlq"; dlq.push(m.id);
      console.log(`${String(t).padStart(4)}  ${m.id}    -        moved to DLQ`);
      continue;
    }
    m.receives++;
    const col = `${String(t).padStart(4)}  ${m.id}    ${m.receives}        `;
    if (m.receives > m.failsFor) {
      m.state = "done";
      console.log(col + "ok, deleted");
    } else {
      m.visibleAt = t + VISIBILITY;
      console.log(col + `FAIL ${m.why}, back at t=${m.visibleAt}`);
    }
  }
}
const stuck = Math.floor(RETENTION / VISIBILITY);
console.log(`\nleft in queue: ${msgs.filter(m => m.state === "queue").length}`);
console.log(`in DLQ: ${dlq.join(", ")}`);
console.log(`with no DLQ, C would fail ${stuck} times before retention ends`);

t(s)  msg  receive  result
   0  A    1        ok, deleted
   0  B    1        FAIL db timeout, back at t=30
   0  C    1        FAIL bad JSON, back at t=30
  30  B    2        ok, deleted
  30  C    2        FAIL bad JSON, back at t=60
  60  C    3        FAIL bad JSON, back at t=90
  90  C    -        moved to DLQ

left in queue: 0
in DLQ: C
with no DLQ, C would fail 11520 times before retention ends

সীমা কত হবে? খুব কম হলে সুস্থ বার্তা DLQ-তে যায়। খুব বেশি হলে খারাপ বার্তা দীর্ঘ সময় worker আটকায়। সাধারণ শুরু ৩ থেকে ৫, আর ব্যর্থ হওয়ার সাধারণ সময় মেপে ঠিক করুন। মনে রাখুন, মোট অপেক্ষা ≈ সীমা × timeout. Service Bus-এ MaxDeliveryCount (লেখার সময়ে default ১০), আর Pub/Sub-এ dead-letter topic-এর maximum delivery attempts একই কাজ করে।

DLQ-তে পড়ার পরে কী

DLQ কোনো সমাধান নয়, একটি হাসপাতালের ওয়ার্ড। সেখানে বার্তা জমে থাকলে অর্ডার আসলে থেমে আছে। তাই তিনটি অভ্যাস:

1. Alarm: DLQ-র গভীরতা ০-এর বেশি হলেই খবর। “কত জমলে” প্রশ্ন নয়, প্রতিটি বার্তাই একজন গ্রাহকের কাজ (পর্ব ৬৬-এর alert নিয়ম দেখুন)।
2. কারণ গোনা: বার্তার সাথে ব্যর্থতার কারণ লগ করুন, তারপর দলবদ্ধ করুন। সব এক কারণ হলে একটি বাগ, ছড়ানো হলে অন্য কিছু।
3. Redrive: কারণ সারার পরে বার্তা মূল queue-তে ফেরান। কিন্তু কারণ না সারিয়ে ফেরালে সব আবার DLQ-তে আসবে। আর সব বার্তা একবারে না ফিরিয়ে হার সীমিত করুন, নইলে নিচের সার্ভিস নতুন করে ডুববে।

এই Bash block ছোট একটি নমুনা গুনে দেখায়, কোন বার্তা ফেরানো নিরাপদ। ইনপুট হাতে লেখা JSON lines. প্রয়োজনীয় হাতিয়ার পর্ব ৯-এ দেখেছেন।

# Count why messages reached the DLQ. Sample data, one JSON object per line.
set -euo pipefail
dlq=$(cat <<'EOF'
{"id":"m-01","queue":"orders","reason":"bad_json","receives":3}
{"id":"m-02","queue":"orders","reason":"timeout","receives":3}
{"id":"m-03","queue":"email","reason":"bad_json","receives":3}
{"id":"m-04","queue":"orders","reason":"unknown_field","receives":3}
{"id":"m-05","queue":"orders","reason":"bad_json","receives":3}
{"id":"m-06","queue":"email","reason":"timeout","receives":3}
{"id":"m-07","queue":"orders","reason":"timeout","receives":3}
{"id":"m-08","queue":"orders","reason":"bad_json","receives":3}
{"id":"m-09","queue":"email","reason":"throttled","receives":3}
{"id":"m-10","queue":"orders","reason":"bad_json","receives":3}
EOF
)
field() { sed -E "s/.*\"$1\":\"([^\"]+)\".*/\1/"; }
count() { sort | uniq -c | awk '{print $1, $2}' | sort -k1,1nr -k2,2; }

echo "total: $(printf '%s\n' "$dlq" | wc -l | tr -d ' ')"
echo "== by reason =="
printf '%s\n' "$dlq" | field reason | count
echo "== by queue and reason =="
printf '%s\n' "$dlq" | awk -F'"' '{print $8 "/" $12}' | count
echo "== safe to redrive (temporary failures) =="
printf '%s\n' "$dlq" | grep -E '"reason":"(timeout|throttled)"' | field id | tr '\n' ' '
echo

total: 10
== by reason ==
5 bad_json
3 timeout
1 throttled
1 unknown_field
== by queue and reason ==
4 orders/bad_json
2 orders/timeout
1 email/bad_json
1 email/throttled
1 email/timeout
1 orders/unknown_field
== safe to redrive (temporary failures) ==
m-02 m-06 m-07 m-09

৫ · ক্রম, FIFO আর batching

সাধারণ queue ক্রমের প্রতিশ্রুতি দেয় না। SQS standard-এ ক্রম “best-effort”: আগে পাঠানো বার্তা পরে আসতে পারে। ক্রম রাখা দামি, কারণ অনেক machine জুড়ে সমান্তরালে চলতে গেলে কাউকে থামতেই হয়।

আগে জিজ্ঞেস করুন, সত্যিই ক্রম লাগবে কি না। অনেক সময় বার্তায় একটি version বা sequence সংখ্যা রাখলেই চলে: পুরোনো সংখ্যা এলে worker সেটি ফেলে দেয়। “Stock ১০ হলো” ধরনের পুরো মান পাঠালে ক্রম আরও কম গুরুত্বপূর্ণ।

FIFO queue আর message group

সত্যিই ক্রম লাগলে FIFO queue. কিন্তু লক্ষ করুন, ক্রম পুরো queue-তে নয়, প্রতিটি message group-এর ভেতরে। লঞ্চঘাটের টিকিটের কাউন্টার ভাবুন: এক কাউন্টারের লাইনে ক্রম আছে, কিন্তু দুই কাউন্টারের মধ্যে কে আগে, তার কোনো মানে নেই। একটি group-এর সামনের বার্তা শেষ না হলে পরেরটি কেউ পায় না।

“Exactly-once” দেখলে সাবধান। SQS FIFO “exactly-once processing” বলে। এর অর্থ, dedup window-র ভেতরে একই deduplication ID-র বার্তা দ্বিতীয়বার ঢোকে না, আর delete হওয়া বার্তা ফেরে না। কিন্তু আপনার worker টাকা কাটার পরে, delete-এর আগে মরলে বার্তা ফিরবেই। তাই FIFO নিলেও idempotent consumer লাগবে। কেন “exactly-once delivery” অসম্ভব, সেই যুক্তি delivery semantics পর্বে.

Batching: বড় হাতা, বড় বিপদ

ঘরে ঘরে একটি করে পার্সেল দেওয়ার বদলে ভ্যান ভরে যাওয়াই সস্তা। Queue-তেও প্রতি API call-এ একাধিক বার্তা (batch) পাঠানো, নেওয়া আর মোছা যায়। SQS-এ লেখার সময়ে একবারে ১০টি পর্যন্ত। লাভ দুটি: কম call মানে কম বিল, আর worker-এর ডেটাবেসে একসাথে লেখা যায়।

আরেকটি সহজ সাশ্রয় long polling. খালি queue-তে বারবার “কিছু আছে?” জিজ্ঞেস না করে worker বলে “২০ সেকেন্ড অপেক্ষা করে বলুন”।

# Example only. Real use needs an account and may cost money.
aws sqs receive-message \
  --queue-url https://sqs.ap-south-1.amazonaws.com/123456789012/orders \
  --max-number-of-messages 10 \
  --wait-time-seconds 20 \
  --visibility-timeout 60

Batching-এর দুটি ফাঁদ:

• এক ব্যর্থ, সবাই আবার। ১০টির batch-এ ৯টি সফল আর ১টি ব্যর্থ হলে, এবং পুরো batch-কে ব্যর্থ জানালে, ৯টি আবার চলবে। সমাধান partial batch response: function শুধু ব্যর্থগুলোর ID ফেরত দেয়। লেখার সময়ে AWS-এ এটি আলাদাভাবে চালু করতে হয়।
• সময় ভাগ হয়ে যায়। ১০টি বার্তা ৩০ সেকেন্ডের timeout পেয়েছে, কাজ একটির পর একটি হলে শেষের দিকেরগুলো সময়ের বাইরে যেতে পারে। Batch-এর মোট সময় দিয়ে timeout হিসাব করুন। আর batch জমার অপেক্ষা বাড়লে latency-ও বাড়ে।

৬ · Fan-out, routing rule, schema আর CloudEvents

অর্ডারের খবর তিনটি সার্ভিসের লাগবে। Topic থেকে সরাসরি সার্ভিসে না পাঠিয়ে প্রায়ই মাঝে প্রতিটির নিজের queue বসানো হয়। এই নকশাকে বলে topic-to-queue fan-out. কেন queue? কারণ topic ধরে রাখতে জানে না, queue জানে। প্রতিটি শ্রোতা নিজের গতিতে চলে, নিজের DLQ রাখে। নিচে দেখুন email সার্ভিস পড়ে গেলে কী হয়।

একটি সূক্ষ্ম বিপদ: ডেটাবেসে লেখা আর publish দুটি আলাদা কাজ। Order service ডেটাবেসে লিখে publish-এর আগেই মরলে ঘটনা হারায়। সমাধান transactional outbox: ঘটনাটি একই transaction-এ একটি টেবিলে লেখা, আর আলাদা process সেটি পাঠায়। বিস্তারিত distributed transaction পর্বে.

Routing rule: কে শুনবে, সেটি বাইরে লেখা

Event bus-এ event pattern লিখে বলা হয় কোন ঘটনা কোন গন্তব্যে যাবে। উদাহরণ: বাংলাদেশের ৫,০০০ টাকা বা বেশি মূল্যের অর্ডার শুধু fraud-check সার্ভিসে। Topic-এও SNS filter policy বা Service Bus subscription filter এই কাজ করে। নিচে EventBridge-ধাঁচের একটি pattern:

{
  "source": ["shop.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": {
    "country": ["BD"],
    "amount": [{ "numeric": [">=", 5000] }]
  }
}

লাভ হলো producer-এর কোড অপরিবর্তিত থাকে। বিপদ হলো নিয়মে বানান ভুল হলে কোনো error আসে না: ঘটনা শুধু কোথাও যায় না। তাই নিয়মও কোড, IaC-তে রাখুন, পরীক্ষা করুন, আর “কোনো নিয়মে মেলেনি” ধরনের metric দেখুন।

Schema: ঘটনা একবার ছাড়লে সেটি public API

একটি ঘটনার কতজন পাঠক, producer জানে না। তাই amount নাম বদলে total করলে এমন কারো কোড ভাঙবে, যাঁকে আপনি চেনেনই না। এজন্য event schema লিখে রাখা হয়, আর নিয়ম সরল: নতুন field যোগ করুন, পুরোনো অর্থ বদলাবেন না, মুছবেন না। ভাঙতেই হলে নতুন version-এর নতুন event type আনুন, কিছুদিন দুটোই চালান। Schema registry কেন্দ্রীয়ভাবে schema রাখে আর পরিবর্তন যাচাই করে: যেমন EventBridge Schema Registry, Confluent Schema Registry. Format আর evolution-এর তত্ত্ব serialization পর্বে.

ঘটনায় কী রাখবেন? দুটি পথ। শুধু পরিচয় পাঠালে (“order-101 হয়েছে”) পাঠককে আবার ফিরে ডাকতে হয়, এতে জোড়া বাড়ে। পুরো তথ্য পাঠালে আকার বাড়ে, আর queue-র আকারের সীমাও আছে। ছবি বা বড় ফাইল হলে object storage-এ রেখে শুধু ঠিকানা পাঠান, একে বলে claim check, লঞ্চের মালের রসিদের মতো। আর গ্রাহকের সংবেদনশীল তথ্য ঘটনায় যত কম, তত ভালো, কারণ সেটি অনেক queue, DLQ আর log-এ ছড়ায়।

CloudEvents: খামের একটি সাধারণ মাপ

প্রতি provider-এর ঘটনার আকার আলাদা হলে প্রতিটি পাঠকে আলাদা কোড লেখা লাগে। CloudEvents হলো CNCF-এর একটি spec, যা ঘটনার খামের মাপ ঠিক করে, ভেতরের চিঠির নয়। Version ১.০ আসে ২০১৯ সালে, আর লেখার সময়ে এটি CNCF-এর graduated প্রকল্প। আবশ্যিক attribute চারটি: id, source, specversion, type. source আর id মিলে ঘটনাকে অনন্য করে, তাই এই জোড়াই ভালো idempotency key.

{
  "specversion": "1.0",
  "id": "evt-7f3a",
  "source": "/shop/orders",
  "type": "com.example.order.placed.v1",
  "subject": "order-101",
  "time": "2026-10-31T09:30:00Z",
  "datacontenttype": "application/json",
  "data": { "orderId": "order-101", "amount": 500, "currency": "BDT" }
}

Azure Event Grid আর Google Eventarc CloudEvents ব্যবহার করে। EventBridge-এর নিজের envelope আছে, তাই সেখানে অনুবাদ লাগতে পারে। এটি vendor lock-in কিছুটা কমায়, কিন্তু মুছে দেয় না: খুঁটিনাটি আচরণ সব জায়গায় এক নয়।

৭ · Workflow — orchestration, choreography আর saga

ধরুন একটি অর্ডারে তিন ধাপ: stock রাখা, টাকা কাটা, courier ডাকা। কোনো ধাপ ব্যর্থ হলে আগেরগুলো ফেরাতে হবে। একাধিক সার্ভিস জুড়ে ডেটাবেসের transaction চলে না। তাই ধাপগুলোকে আলাদা local transaction ধরে, প্রতিটির উল্টো কাজ রাখা হয়। একেই বলে saga, আর উল্টো কাজকে compensating action. ধারণাটি Hector Garcia-Molina আর Kenneth Salem-এর ১৯৮৭ সালের প্রবন্ধ থেকে, পুরো তত্ত্ব distributed transaction পর্বে. এখানে প্রশ্ন একটিই: সাজাবে কে?

নিচে একটি workflow-এর ব্যর্থতা ধাপে ধাপে দেখুন। Courier API তিনবার চেষ্টাতেও উত্তর দেয় না, তাই engine compensation চালায়।

ওপরের BookCourier ধাপটি AWS Step Functions-এর Amazon States Language-এ লিখলে এমন দেখায়। MaxAttempts: 2 মানে প্রথম চেষ্টার পরে আরও ২ বার, মোট ৩:

{
  "BookCourier": {
    "Type": "Task",
    "Resource": "arn:aws:lambda:ap-south-1:123456789012:function:book-courier",
    "Retry": [{
      "ErrorEquals": ["States.TaskFailed"],
      "IntervalSeconds": 2,
      "BackoffRate": 2,
      "MaxAttempts": 2
    }],
    "Catch": [{ "ErrorEquals": ["States.ALL"], "Next": "RefundPayment" }],
    "Next": "ConfirmOrder"
  }
}

এবার একই ব্যর্থতা দুই পথে চালিয়ে দেখুন। তৃতীয় run-এ এক দল ভুলে একটি subscription তুলে দিয়েছে।

// One order, courier booking fails. Same business, two ways of joining services.
const act = {
  reserve: s => { s.stock = 1; }, charge: s => { s.money = 500; },
  refund: s => { s.money = 0; }, release: s => { s.stock = 0; }, cancel: s => { s.order = "CANCELLED"; } };
const fresh = () => ({ money: 0, stock: 0, order: "PENDING" });
function orchestrate() {
  const s = fresh(), history = []; let messages = 0;
  const call = (name, ok = true) => {          // one command + one reply
    messages += 2; if (ok) act[name](s);
    history.push(name + (ok ? " ok" : " FAIL"));
  };
  call("reserve"); call("charge"); call("book", false);
  call("refund"); call("release"); call("cancel");   // compensate in reverse
  console.log(`ORCHESTRATION messages=${messages}\n  ${history.join(" > ")}`);
  console.log("  final", JSON.stringify(s));
}
function choreograph(rules, label) {
  const s = fresh(), seen = [], bus = ["OrderPlaced"];
  while (bus.length) {
    const ev = bus.shift(), rule = rules[ev] || {};  // no rule: the event just ends
    seen.push(ev);
    if (rule.do) act[rule.do](s);
    if (rule.emit) bus.push(rule.emit);
  }
  console.log(`CHOREOGRAPHY ${label} events=${seen.length}\n  ${seen.join(" > ")}`);
  console.log("  final", JSON.stringify(s));
}
const rules = { OrderPlaced: { do: "reserve", emit: "StockReserved" },
  StockReserved: { do: "charge", emit: "PaymentDone" }, PaymentDone: { emit: "CourierFailed" },
  CourierFailed: { do: "refund", emit: "Refunded" }, Refunded: { do: "release", emit: "StockFreed" },
  StockFreed: { do: "cancel", emit: "OrderCancelled" } };
orchestrate(); choreograph(rules, "all rules");
const broken = { ...rules }; delete broken.Refunded;   // one team dropped a subscription
choreograph(broken, "rule missing");

ORCHESTRATION messages=12
  reserve ok > charge ok > book FAIL > refund ok > release ok > cancel ok
  final {"money":0,"stock":0,"order":"CANCELLED"}
CHOREOGRAPHY all rules events=7
  OrderPlaced > StockReserved > PaymentDone > CourierFailed > Refunded > StockFreed > OrderCancelled
  final {"money":0,"stock":0,"order":"CANCELLED"}
CHOREOGRAPHY rule missing events=5
  OrderPlaced > StockReserved > PaymentDone > CourierFailed > Refunded
  final {"money":0,"stock":1,"order":"PENDING"}

এই engine-গুলোর মূল ধারণা durable execution: প্রতিটি ধাপের ফল লিখে রাখা, যাতে crash-এর পরে মাঝখান থেকে চলা যায়। তত্ত্ব আছে workflow engine পর্বে.

কখন কোনটি? ধাপে ক্রম আছে, compensation আছে, টাকা জড়িত, আর কেউ জানতে চায় “এই অর্ডার এখন কোথায়?”: orchestration. স্বাধীন প্রতিক্রিয়া, যেখানে কেউ ব্যর্থ হলেও বাকিরা চিন্তিত নয়, যেমন email, report, cache মোছা: choreography. বাস্তবে দুটোই মেশে: এক দলের সার্ভিসগুলোর ভেতরে workflow, দলগুলোর মধ্যে ঘটনা।

৮ · চালানো আর মাপা — queue depth, autoscaling আর খরচ

Queue-ভিত্তিক সিস্টেম নীরবে পিছিয়ে পড়ে। সব service সবুজ, error নেই, অথচ ক্রেতার email আসে ৪০ মিনিট পরে। তাই CPU নয়, queue-কেই মাপতে হয়:

মনে রাখুন, শুধু “মোট depth” autoscaling-এর ভালো সংকেত নয়। ১,০০০ বার্তা ২টি worker-এর জন্য বিপদ, ১০০টির জন্য সামান্য। ভালো সংকেত হলো worker-প্রতি জমে থাকা কাজ, যা পর্ব ১৭-এর target tracking-এ বসানো যায়। Kubernetes-এ একই কাজ করে KEDA, যা queue দেখে worker Pod বাড়ায়, ০-তেও নামাতে পারে।

খরচের হিসাব (সব দাম অনুমিত)

নিচের দাম শেখার জন্য ধরা গোল সংখ্যা, কোনো provider-এর আসল দাম নয়। পরিকল্পনার আগে pricing পাতা দেখুন। ধরে নিই: queue-তে প্রতি ১০ লাখ API call $০.৪০, topic-এ প্রতি ১০ লাখ publish $০.৫০, queue-তে পৌঁছে দেওয়া বিনা খরচে, workflow-এ প্রতি ১০ লাখ ধাপ $২৫. মাসে ৩০ লাখ অর্ডার, ৩০ দিনের মাস।

তিনটি শিক্ষা। এক, খালি queue-র poll আসল কাজের চেয়েও বেশি বিল আনতে পারে: $১০.৩৭ বনাম $৩.৬০। Long polling এক লাইনের সমাধান। দুই, batching এখানে বিল দশ ভাগের এক করে। তিন, workflow fan-out-এর প্রায় ৩৭ গুণ। এটি অপচয় নয়, আপনি দৃশ্যমানতা আর ব্যর্থতা সামলানোর দাম দিচ্ছেন। কিন্তু প্রতিটি email-এর জন্য নয়, টাকা-জড়িত পথের জন্যই সেটি মানায়। লেখার সময়ে Step Functions-এর Express ধরনের হিসাব আলাদা, তাই বেশি পরিমাণে সেটি যাচাই করুন। Queue-র বিল সাধারণত worker-এর compute আর ডেটা পাঠানোর খরচের তুলনায় ছোট। পুরো বিলের নকশা পর্ব ৭২-এ। আর নিজে চেষ্টা করতে চাইলে মনে রাখুন, আসল cloud-এ খরচ হতে পারে; পরীক্ষা শেষে queue, topic আর rule মুছে দিন।

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

AI খুব দ্রুত queue, Lambda আর Terraform লিখে দেয়। সব ঠিক থাকলে যে পথ চলে, সেটি সাধারণত ঠিকই থাকে। সমস্যা থাকে ঠিক সেখানে, যা এই পর্বের বিষয়: duplicate, ব্যর্থতা, খরচ।

AI-এর নকশা হাতে পেলে — চেকলিস্ট

• প্রতিটি queue-র DLQ, সীমা আর DLQ alarm আছে
• একই বার্তা দুবার পাঠিয়ে দেখেছি, ফল একবারের সমান
• Worker কাজের মাঝখানে বন্ধ করে দেখেছি, বার্তা ফিরে আসে আর কাজ হারায় না
• Timeout মাপা p99-এর চেয়ে বড়; retry-তে backoff আর jitter আছে
• IAM-এ * নেই; queue-র policy আর encryption দেখেছি
• সব কিছু throwaway পরিবেশে চালিয়েছি, terraform plan পড়েছি, কোনো secret prompt-এ দিইনি
• পরিমাণ × দাম হাতে হিসাব করেছি, budget alert বসিয়েছি, পরীক্ষা শেষে সব মুছেছি