Message queue — producer, consumer, acknowledgement, retry আর dead letter queue

১ · Queue কেন — সরাসরি ডাকার বদলে মাঝখানে একটি সারি

একটি ব্যস্ত রেস্তোরাঁর কথা ভাবুন। ওয়েটার অর্ডার নিয়ে রান্নাঘরের দরজার হুকে স্লিপটি ঝুলিয়ে দেন, তারপর পরের টেবিলে যান। বাবুর্চি হুক থেকে একটি একটি স্লিপ নেন। ওয়েটারকে রান্না শেষ হওয়া পর্যন্ত দাঁড়িয়ে থাকতে হয় না। একজন বাবুর্চি চায়ের বিরতিতে গেলেও অর্ডার নেওয়া থামে না। আর সন্ধ্যার ভিড়ে স্লিপ হুকে জমে, রান্নাঘর ভাঙে না। এই হুকটিই একটি message queue.

Software-এ একই ঘটনা ঘটে। একটি অনলাইন দোকানের (কাল্পনিক) “অর্ডার দিন” বোতামের পেছনে অনেক কাজ: database-এ অর্ডার লেখা, SMS রসিদ, ইমেইল, গুদামকে খবর, লয়্যালটি পয়েন্ট, analytics. সব কাজ যদি একই অনুরোধের ভেতরে একটির পর একটি ডাকা হয় (synchronous call), তিনটি সমস্যা হয়:

• Latency যোগ হয়: SMS gateway ২ সেকেন্ড নিলে ব্যবহারকারীও ২ সেকেন্ড বেশি অপেক্ষা করেন — অথচ SMS-এর জন্য অপেক্ষার কোনো দরকার ছিল না।
• Availability গুণ হয়: পাঁচটি সেবা প্রত্যেকে ৯৯.৯% চালু থাকলে সবাই একসাথে চালু থাকে প্রায় ৯৯.৫% সময় (পর্ব ৫)। ইমেইল সেবা বন্ধ বলে অর্ডারই ব্যর্থ — এটি অন্যায্য।
• গতি বাঁধা থাকে: ঈদের সেলে অর্ডার দশ গুণ হলে SMS gateway-কেও তখনই দশ গুণ চাপ নিতে হয়, যদিও SMS পাঁচ মিনিট পরে গেলেও চলত।

Queue এই তিনটি বাঁধন খোলে। অর্ডার সার্ভিস শুধু একটি বার্তা রাখে — “অর্ডার ১০৪২-এর SMS পাঠাতে হবে” — আর সঙ্গে সঙ্গে ব্যবহারকারীকে বলে “অর্ডার গৃহীত”. বাকি কাজ পেছনে worker-রা করে। একে বলে asynchronous কাজ।

লক্ষ করুন, queue ক্ষমতা বাড়ায় না — শুধু সময় কেনে। দীর্ঘ সময়ের গড়ে λ যদি N·μ ছাড়ায়, queue অসীমভাবে বাড়বে; তখন consumer বাড়াতেই হবে, নয়তো উৎসকে থামাতে হবে — পর্ব ১৮-এর bounded queue আর backpressure দিয়ে। Queue তখনই কাজের, যখন গড় চাপ ক্ষমতার নিচে কিন্তু peak ওপরে।

২ · Point-to-point মডেল — producer, broker আর competing consumers

সবচেয়ে প্রচলিত queue হলো point-to-point: প্রতিটি বার্তা একজন consumer-ই পায় আর প্রক্রিয়া করে। চরিত্র তিনটি:

• Producer — বার্তা বানায় আর পাঠায় — একে বলে publish বা send. বার্তায় থাকে একটি অনন্য id, কাজের বিবরণ (body, প্রায়ই JSON বা Protobuf — পর্ব ১২) আর কিছু header (কখন বানানো, কতবার চেষ্টা হলো)।
• Broker — মাঝের সেবা, যা বার্তা গ্রহণ করে, জমা রাখে, consumer-কে দেয় আর কাজ শেষের খবর (ack) পেলে মোছে। RabbitMQ, Amazon SQS-ধাঁচের cloud queue, বা Redis — উদাহরণ অংশ ৮-এ।
• Consumer — বার্তা তুলে নিয়ে কাজ করে, তারপর ack পাঠায়। একই queue-তে অনেক consumer থাকলে তারা বার্তা ভাগ করে নেয় — কে আগে খালি, সে পরেরটি পায়।

শেষেরটির নাম competing consumers: ব্যাংকের টোকেন ব্যবস্থার মতো। একটি সারি, কয়েকটি কাউন্টার; যে কাউন্টার খালি হয়, পরের টোকেন সেখানে ডাকা হয়। কাউন্টার বাড়ালে সারি দ্রুত চলে, আর কোনো টোকেন দুই কাউন্টারে যায় না। Consumer stateless হলে (পর্ব ১৩) এভাবে horizontal scaling সবচেয়ে সহজ।

এবার একটি বার্তার পুরো জীবন দেখুন — producer থেকে ack পর্যন্ত। ধরা যাক broker-এর visibility timeout ৩০ সেকেন্ড (অংশ ৪-এ বিস্তারিত)।

Operating system-এর ভেতরেও একই ধারণা আছে: একই যন্ত্রের দুটি process-এর মধ্যে message queue (Operating Systems · Inter-process communication), আর একটি সীমিত buffer-এ producer-consumer সমস্যা (Operating Systems · ক্লাসিক সমস্যা)। System design-এর queue তারই network-জোড়া, টেকসই রূপ, যেখানে যেকোনো অংশ যেকোনো মুহূর্তে বিকল হতে পারে।

৩ · ভিড়ে queue কত বাড়ে — consumer-এর সংখ্যা হিসাব করা

অংশ ১-এর সূত্রটি এবার একটি simulation-এ যাচাই করুন। স্বাভাবিক চাপ সেকেন্ডে ২৫টি বার্তা; ৬০ থেকে ৮০ সেকেন্ডে একটি ঢেউ, সেকেন্ডে ৮০টি। প্রতিটি consumer গড়ে ১০০ ms নেয় (সেকেন্ডে ১০টি)। সময় আর আগমন দুটোই এলোমেলো — exponential service আর Poisson আগমন। Consumer ২, ৪ আর ৮ জন হলে কী হয়?

আগে মাথায় হিসাব করুন। N = ২-এ ক্ষমতা ২০, যা স্বাভাবিক চাপ ২৫-এরও কম — queue সারাক্ষণ বাড়বে। N = ৪-এ ক্ষমতা ৪০: স্বাভাবিক দিনে ঠিক, ঢেউয়ে প্রায় ৮০০ জমবে। N = ৮-এ ক্ষমতা ৮০: ঢেউয়ের সমান, তাই সামান্য জমা।

// Bursty producer -> one queue -> N competing consumers (FIFO). Seeded, repeatable.
// Normal load 25 msg/s; a burst of 80 msg/s from t = 60 s to t = 80 s; run 180 s.
// Each consumer needs 100 ms per message on average (exponential), i.e. 10 msg/s.
function rng(seed) {                                   // mulberry32
  return () => { seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const rate = (t) => (t >= 60 && t < 80 ? 80 : 25), END = 180, S = 0.1;
const SAMPLES = [30, 60, 70, 80, 100, 120, 150, 180];
function run(N) {
  const rand = rng(7), exp = (m) => -Math.log(1 - rand()) * m;
  const free = new Array(N).fill(0), arr = [], start = [];
  for (let t = exp(1 / rate(0)); t < END; t += exp(1 / rate(t))) {
    let k = 0; for (let i = 1; i < N; i++) if (free[i] < free[k]) k = i;  // first free consumer
    const s = Math.max(t, free[k]); free[k] = s + exp(S);
    arr.push(t); start.push(s);
  }
  const depth = SAMPLES.map((x) => arr.filter((a, i) => a <= x && start[i] > x).length);
  const waits = arr.map((a, i) => start[i] - a).sort((a, b) => a - b);
  const p99 = waits[Math.ceil(0.99 * waits.length) - 1];
  return { depth, p99, n: arr.length };
}
console.log("depth at t(s):  " + SAMPLES.map((x) => String(x).padStart(5)).join("") + "   wait p99");
for (const N of [2, 4, 8]) {
  const r = run(N);
  console.log(("N = " + N + " (" + N * 10 + "/s)").padEnd(16) + r.depth.map((d) => String(d).padStart(5)).join("") +
    (r.p99 < 1 ? (r.p99 * 1000).toFixed(0) + " ms" : r.p99.toFixed(1) + " s").padStart(11));
}

depth at t(s):     30   60   70   80  100  120  150  180   wait p99
N = 2 (20/s)      233  445 1022 1597 1618 1708 1787 1940     96.0 s
N = 4 (40/s)        2    0  342  676  324   51    0    0     15.7 s
N = 8 (80/s)        0    0    2    3    0    0    0    0     213 ms

কতজন consumer — Little-এর সূত্রে

একটি consumer process প্রায়ই একসাথে কয়েকটি বার্তা প্রক্রিয়া করে, thread বা async দিয়ে। তখন প্রশ্ন হয় “একসাথে কতগুলো কাজ চলবে?” পর্ব ৪-এর Little-এর সূত্র L = λW সরাসরি উত্তর দেয়: সেকেন্ডে ২০০টি SMS, প্রতিটি gateway call ০.৫ সেকেন্ড — একসাথে চলবে গড়ে ২০০ × ০.৫ = ১০০টি কাজ। প্রতিটি process ২০টি concurrent কাজ চালালে অন্তত ৫টি process, আর ৭০–৮০% ব্যস্ততার লক্ষ্যে ৭টি। নিচের ধাপ (gateway, database) সেই ১০০টি একসাথে নিতে পারবে কি না, সেটিও দেখুন — নইলে consumer বাড়ানো শুধু চাপ সরায়।

৪ · Acknowledgement — বার্তা কখন মুছবে, আর crash হলে কী হয়

Queue-র সবচেয়ে গুরুত্বপূর্ণ প্রশ্ন: broker কখন বুঝবে কাজটি শেষ, আর বার্তাটি মোছা নিরাপদ? উত্তর acknowledgement বা ack — consumer-এর পাঠানো “কাজ শেষ” সংকেত। দুটি ধরন:

Auto ack দ্রুত আর সহজ, কিন্তু শুধু সেখানে চলে যেখানে বার্তা হারালে ক্ষতি নেই — যেমন প্রতি সেকেন্ডের তাপমাত্রার রিডিং, যার পরেরটি এক সেকেন্ড পরেই আসছে। টাকা, অর্ডার আর নোটিফিকেশনে manual ack.

Broker কীভাবে বোঝে consumer মারা গেছে — দুই ধাঁচ

• Visibility timeout (SQS-ধাঁচ): consumer বার্তা নিলে সেটি নির্দিষ্ট সময়ের জন্য লুকানো থাকে। সময়ের মধ্যে consumer বার্তাটি মুছে দিলে (delete — এখানে এটিই ack) শেষ; না মুছলে সময় শেষে বার্তা আবার দেখা যায়, আর অন্য কেউ পায়। Broker consumer-এর সাথে কোনো সংযোগ ধরে রাখে না; সময়ই একমাত্র সংকেত — একটি lease-এর মতো (পর্ব ৪৩)। Amazon SQS-এর ডকুমেন্টেশন অনুযায়ী, লেখার সময়ে ডিফল্ট ৩০ সেকেন্ড আর সর্বোচ্চ ১২ ঘণ্টা, আর লম্বা কাজে consumer মাঝপথে সময় বাড়াতে পারে।
• সংযোগ-ভিত্তিক ack (RabbitMQ-ধাঁচ): consumer একটি খোলা সংযোগে বার্তা পায়। কাজ শেষে ack দেয়; প্রক্রিয়া করতে না পারলে nack বা reject দেয় — সাথে বলে আবার queue-তে ফেরাবে (requeue) কি না। সংযোগ বা channel কেটে গেলে ack-না-পাওয়া সব বার্তা আবার queue-তে ফেরে। RabbitMQ-র নতুন সংস্করণে ack-এর জন্য একটি সময়সীমাও আছে (মান সংস্করণ আর setting-ভেদে আলাদা)।

Redis Streams-এ তৃতীয় একটি রূপ: consumer group-এ পড়া বার্তা একটি pending তালিকায় থাকে, XACK-এ সরে; অনেকক্ষণ pending থাকা বার্তা অন্য consumer দাবি করে নিতে পারে — XCLAIM বা XAUTOCLAIM দিয়ে। নাম আলাদা, ধারণা এক: ack না আসা পর্যন্ত বার্তা কারো দায়িত্বে থাকে, আর দায়িত্বপ্রাপ্ত হারিয়ে গেলে বার্তা ফেরে।

এখানেই redelivery-র জন্ম, আর তার সাথে duplicate-এর। নিচের stepper-এ consumer কাজ শেষ করে, কিন্তু ack দেওয়ার আগেই মারা যায়। কাজ: গ্রাহক ৮৮-এর হিসাবে ৫০ লয়্যালটি পয়েন্ট যোগ করা। Visibility timeout ৩০ সেকেন্ড।

Crash ছাড়াও duplicate আসে: কাজ visibility timeout-এর চেয়ে লম্বা হলে প্রথম consumer কাজ করছে, অথচ বার্তা আবার দেখা দেয় আর দ্বিতীয়জনও শুরু করে। Confirm হারালে producer-ও একই বার্তা আবার পাঠায়। তাই নিয়ম সরল: যেকোনো queue-র consumer ধরে নেবে যে প্রতিটি বার্তা একাধিকবার আসতে পারে।

// Illustrative consumer loop. "queue" and "db" are made-up clients, not a real library.
while (running) {
  const batch = queue.receive({ max: 10, waitSeconds: 20 });   // long poll, small batch
  for (const msg of batch) {
    try {
      db.transaction((tx) => {
        if (!tx.insertIfAbsent("processed", msg.id)) return;      // seen before: skip effect
        tx.addPoints(msg.body.customer, msg.body.points);         // the real effect
      });                                                         // both commit together
      queue.ack(msg);                                             // ack only AFTER commit
    } catch (e) {
      if (isPermanent(e)) queue.deadLetter(msg, e.message);       // bad message: stop retrying
      else queue.retryLater(msg, backoffWithJitter(msg.receiveCount)); // transient: wait, retry
    }
  }
}

তিনটি জিনিস লক্ষ করুন: effect আর “দেখা হয়েছে” চিহ্ন একই transaction-এ; ack commit-এর পরে; আর ত্রুটি দুই রকম — ক্ষণিকের (network, timeout) আর স্থায়ী (ভুল ডেটা)। বাইরের সেবার effect (SMS, পেমেন্ট gateway) একই transaction-এ রাখা যায় না; সেখানে সেবাটির idempotency key (পর্ব ৮) পাঠান, যাতে দ্বিতীয় অনুরোধ নতুন কাজ না বানায়।

৫ · Retry, backoff, poison message আর dead letter queue

কাজ ব্যর্থ হলে আবার চেষ্টা স্বাভাবিক — SMS gateway এক মুহূর্ত ব্যস্ত ছিল, database failover চলছিল। কিন্তু কীভাবে আবার চেষ্টা, তা গুরুত্বপূর্ণ:

• সঙ্গে সঙ্গে requeue নয়: nack-এ বার্তা সঙ্গে সঙ্গে ফিরলে consumer সেটি আবার মুহূর্তেই পায় — gateway তখনো বিকল, আবার ব্যর্থ। সেকেন্ডে হাজারবার এই ঘূর্ণি CPU পোড়ায় আর log ভরায়, আর বিকল সেবার ওপর চাপ বাড়ায় (retry storm, পর্ব ১৮)।
• Exponential backoff আর jitter: প্রতিবার অপেক্ষা দ্বিগুণ — যেমন ১০, ২০, ৪০ সেকেন্ড — সাথে এলোমেলো অংশ, যাতে হাজারো বার্তা একই মুহূর্তে না ফেরে। Queue-তে এর উপায়: visibility timeout বাড়িয়ে দেওয়া (SQS-ধাঁচ), বা delay-সহ আলাদা retry queue (RabbitMQ-তে TTL আর dead-letter exchange দিয়ে প্রচলিত কৌশল)।
• চেষ্টার সীমা: প্রতিটি বার্তার একটি max receive count — যেমন ৩ বা ৫। সীমা পেরোলে বার্তা আর মূল queue-তে নয়।

Poison message — যে বার্তা কখনো সফল হবে না

কিছু বার্তা যতবারই চেষ্টা করুন, ব্যর্থ হবে: JSON ভাঙা, পুরোনো schema, টাকার ঘরে সংখ্যার বদলে লেখা, বা এমন গ্রাহক যিনি মুছে গেছেন। এমন বার্তার নাম poison message. সীমা না থাকলে এটি চিরকাল ঘোরে: প্রতিবার consumer-এর সময় খায়, কখনো consumer-কেই crash করায়। আর FIFO queue-তে (অংশ ৬) পেছনের সবাইকে আটকে রাখে।

সমাধান dead letter queue (DLQ): সীমা পেরোনো বার্তা একটি আলাদা queue-তে সরে, সাথে ত্রুটির কারণ। মূল queue চলতে থাকে; মানুষ বা একটি tool পরে DLQ দেখে, কোড ঠিক করে, তারপর বার্তাগুলো মূল queue-তে ফেরত পাঠায় — একে বলে redrive. ডাকঘরের “ঠিকানা পাওয়া যায়নি” তাকের মতো — চিঠি ফেলে দেওয়া হয় না, আবার সাধারণ বাছাইয়ের পথও আটকায় না।

# SQS-style: a redrive policy on the main queue (a JSON queue attribute)
RedrivePolicy      = {"deadLetterTargetArn": "<ARN of payments-dlq>", "maxReceiveCount": "3"}
VisibilityTimeout  = 60          # seconds; longer than the slowest normal job

# RabbitMQ-style: arguments when declaring a quorum queue
x-queue-type            = quorum
x-dead-letter-exchange  = payments.dlx    # where rejected or expired messages go
x-delivery-limit        = 3               # quorum queues: give up after this many tries
x-message-ttl           = 86400000        # milliseconds (1 day)

এবার সব একসাথে: ১০,০০০টি বার্তা, কাজ গড়ে ৩ সেকেন্ড (exponential), প্রতিটি গ্রহণে ২% সম্ভাবনায় কাজের আগে crash আর ২% সম্ভাবনায় কাজের পরে কিন্তু ack-এর আগে crash; ০.৩% বার্তা poison. Visibility timeout (VT) ৫, ১৫ আর ৬০ সেকেন্ড হলে কী হয়?

// At-least-once queue with a visibility timeout (VT) and max receive count 3 -> DLQ.
// 10,000 messages. Work takes ~3 s on average (exponential). Per receive:
// 2% the consumer crashes BEFORE doing the work, 2% crashes AFTER the work but BEFORE ack.
// If work takes longer than VT, the message becomes visible again and is redelivered
// (the slow consumer still finishes, so the work happens twice). 0.3% are poison messages:
// they crash the consumer every time.
function rng(seed) {                                   // mulberry32
  return () => { seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const MSGS = 10000, MAX_RECEIVE = 3;
function run(VT) {
  const rand = rng(31);
  let deliveries = 0, effects = 0, dupEffects = 0, dlq = 0, dlqHealthy = 0;
  for (let m = 0; m < MSGS; m++) {
    const poison = rand() < 0.003; let done = 0, acked = false;
    for (let r = 1; r <= MAX_RECEIVE && !acked; r++) {
      deliveries++;
      const u = rand(), work = -Math.log(1 - rand()) * 3;     // seconds
      if (poison || u < 0.02) continue;                       // crash before work: no effect
      done++; effects++; if (done > 1) dupEffects++;          // the side effect happened
      if (u < 0.04) continue;                                 // crash after work, no ack
      if (work > VT) continue;                                // too slow: redelivered meanwhile
      acked = true;                                           // ack in time: message deleted
    }
    if (!acked) { dlq++; if (!poison) dlqHealthy++; }
  }
  return [VT + " s", deliveries, effects, dupEffects, dlq, dlqHealthy];
}
const w = [6, 12, 9, 13, 6, 13];
console.log(["VT", "deliveries", "effects", "dup effects", "DLQ", "DLQ healthy"].map((h, i) => h.padStart(w[i])).join(""));
for (const VT of [5, 15, 60]) console.log(run(VT).map((v, i) => String(v).padStart(w[i])).join(""));

    VT  deliveries  effects  dup effects   DLQ  DLQ healthy
   5 s       12693    12361         2392   135          104
  15 s       10494    10204          234    30            0
  60 s       10440    10147          176    29            0

৬ · ক্রম — FIFO বনাম best-effort, আর message group

অনেক queue বার্তার ক্রম কঠোরভাবে রাখে না। SQS-এর standard queue-র মতো সেবাগুলো ডকুমেন্টেশনে স্পষ্ট বলে: ক্রম best-effort, আর বার্তা কখনো একাধিকবার আসতে পারে। কেন? সবচেয়ে সরল কারণ competing consumers নিজেই:

• বার্তা ১ গেল C1-এ, বার্তা ২ গেল C2-তে। C1 ধীর, তাই ২-এর কাজ আগে শেষ। Queue ক্রমে দিলেও কাজ ক্রমে হলো না।
• বার্তা ১ ব্যর্থ হয়ে retry-তে গেল; ততক্ষণে ২, ৩, ৪ শেষ। Retry ক্রম ভাঙে।

সব কাজে ক্রম লাগেও না — একশো জনের SMS কে আগে গেল, তাতে কিছু আসে যায় না। কিন্তু একই অ্যাকাউন্টের “জমা ৫০০” আর “তোলা ৩০০” উল্টো ক্রমে হলে মাঝখানে ব্যালান্স ঋণাত্মক দেখাতে পারে। এর দুটি সমাধান:

Message group-এর দাম head-of-line blocking: একটি group-এর মাথার বার্তা ব্যর্থ হলে সেই group-এর বাকি সবাই অপেক্ষা করে। Poison message এখানে আরও বিপজ্জনক — সীমা আর DLQ ছাড়া একটি অ্যাকাউন্টের সব লেনদেন চিরকাল আটকে থাকত। আর group যত কম, সমান্তরালতা তত কম: একটিমাত্র group মানে একজন consumer-এর গতি।

৭ · Prefetch, priority, delay, TTL আর durability

Prefetch, batching আর consumer concurrency

একটি একটি করে বার্তা আনলে প্রতিটির জন্য broker পর্যন্ত একটি round trip লাগে। কাজ ৫ ms আর round trip ২ ms হলে consumer-এর প্রায় ২৯% সময় অপেক্ষায় যায়। Prefetch এর সমাধান: broker আগেভাগে কয়েকটি বার্তা consumer-এর কাছে পাঠিয়ে রাখে (RabbitMQ-তে prefetch count, SQS-ধাঁচে এক অনুরোধে সর্বোচ্চ কয়েকটি বার্তা আর long polling, যাতে খালি queue-তে বারবার জিজ্ঞেস করতে না হয়)। Ack-ও একসাথে কয়েকটির জন্য দেওয়া যায় — batching.

কিন্তু prefetch বড় হলে দুটি সমস্যা: একটি consumer অনেক বার্তা ধরে বসে থাকে, অন্যরা অলস — বণ্টন অসম; আর সে crash করলে সবগুলো একসাথে ফেরে, যাদের কিছু অর্ধেক হয়ে থাকতে পারে। শুরুর নিয়ম: prefetch ≈ একসাথে যতগুলো কাজ consumer সত্যিই চালায়, তার একটু বেশি। লম্বা কাজে (মিনিটের হিসাবে) prefetch ১।

Priority queue — জরুরি কাজ আগে

OTP আর মাসিক বিবরণীর ইমেইল একই queue-তে থাকলে, ১০ লাখ বিবরণীর পেছনে একটি OTP ঘণ্টাখানেক আটকে থাকতে পারে। Priority queue-তে বার্তার অগ্রাধিকার থাকে, বেশি অগ্রাধিকারের বার্তা আগে দেওয়া হয় — ভেতরে প্রায়ই একটি heap-এর মতো কাঠামো — বিস্তারিত DSA · Heap আর priority queue-এ। RabbitMQ-র কিছু queue ধরন এটি দেয় (সীমিত কয়েকটি স্তরে, সংস্করণভেদে আলাদা)। তবে অনেক দল এর চেয়ে সরল পথ নেয়: আলাদা queue, আলাদা consumer pool — জরুরিদের নিজস্ব worker থাকে, তাই নিচু শ্রেণির ভিড়ে তারা আটকায় না (পর্ব ১৮-এর bulkhead-এর ধারণা)। কঠোর priority-তে নিচু শ্রেণি চিরকাল অপেক্ষা করতে পারে (starvation); সেটিও মাপুন।

Delayed message আর message TTL

• Delayed message: “৩০ মিনিট পরে দেখুন পেমেন্ট এসেছে কি না, না এলে অর্ডার বাতিল।” বার্তা queue-তে ঢোকে, কিন্তু নির্দিষ্ট সময় পরে দেখা দেয়। SQS-ধাঁচে delay-র সীমা ছোট (লেখার সময়ে সর্বোচ্চ ১৫ মিনিট); RabbitMQ-তে plugin বা TTL আর dead-letter-এর কৌশল। দিন বা মাসের হিসাবের সময়সূচির জন্য scheduler বা workflow engine ভালো — পর্ব ৩৭-এর background job আর workflow-এ দেখবেন।
• Message TTL: একটি বার্তার মেয়াদ। “তিন মিনিটের OTP” পাঁচ মিনিট পরে পাঠানো অর্থহীন, বরং বিভ্রান্তিকর; মেয়াদ পেরোলে broker সেটি ফেলে দেয় বা DLQ-তে পাঠায়। Consumer-এর দিকেও যাচাই রাখুন: বার্তায় “এর পরে বাতিল” সময় লিখে রাখুন। এটি পর্ব ১৮-এর deadline-এর ধারণাই।

Durability — বার্তা কি broker-এর restart-এ টিকে থাকবে?

Persistent বার্তা broker disk-এ লেখে (প্রায়ই fsync সহ), তাই restart-এ টেকে; transient বার্তা শুধু memory-তে — দ্রুত, কিন্তু restart-এ হারায়। RabbitMQ-র ক্লাসিক জগতে queue “durable” আর বার্তা “persistent” — দুটিই আলাদা করে ঠিক করতে হয়; একটি না থাকলে restart-এ বার্তা হারাতে পারে।

কিন্তু একটি disk-ও নষ্ট হয়। তাই অনেক broker বার্তা একাধিক node-এ replicate করে (পর্ব ২২)। RabbitMQ-র quorum queue এর জন্য Raft consensus ব্যবহার করে (পর্ব ৪২): বার্তা গ্রহণের নিশ্চয়তা আসে বেশিরভাগ replica লেখার পরে। Durability-র শিকল সম্পূর্ণ হয় তখনই, যখন তিনটিই আছে: producer confirm-এর অপেক্ষা করে, broker disk আর replica-তে লেখে, consumer কাজের পরে ack দেয়। যেকোনো একটি বাদ পড়লে শিকল সেখানেই ছেঁড়ে।

৮ · চালানো আর মাপা — queue depth, autoscaling আর broker বাছাই

একটি queue-র স্বাস্থ্য বোঝার দুটি সংখ্যা: queue depth (কতগুলো বার্তা অপেক্ষায়) আর সবচেয়ে পুরোনো বার্তার বয়স। প্রথমটি বলে কত কাজ জমা, দ্বিতীয়টি বলে ব্যবহারকারী কত দেরি টের পাচ্ছেন। Log-ভিত্তিক stream-এ একই জিনিসের নাম consumer lag — লেখা আর পড়ার অবস্থানের ব্যবধান (পর্ব ৩৩)। Consumer-এর CPU এখানে প্রায়ই ভুল সংকেত: SMS gateway-র অপেক্ষায় বসে থাকা consumer-এর CPU ৫%, অথচ queue-তে এক লাখ বার্তা।

পর্ব ১৩-এ দেখেছেন, পেছনের worker-এর জন্য autoscaling-এর সেরা metric queue-র দৈর্ঘ্য। এবার চারটি নীতি পাশাপাশি চালান: স্বাভাবিক চাপ সেকেন্ডে ৩০, ৩০০ থেকে ৯০০ সেকেন্ডে ১৫০; প্রতিটি consumer সেকেন্ডে ১০; নতুন consumer চালু হতে ৬০ সেকেন্ড।

// Fixed consumers vs autoscaling on queue depth. 1-second steps, fluid model.
// Arrivals: 30 msg/s, 150 msg/s from t = 300 s to 900 s, then 30 msg/s; run 3600 s.
// One consumer handles 10 msg/s. Autoscaler checks every 30 s (min 2, max 20);
// new consumers need 60 s to start; scale in by at most 1 consumer per check.
const RATE = (t) => (t >= 300 && t < 900 ? 150 : 30), END = 3600, MU = 10;
const POLICIES = [
  { name: "fixed 8", fixed: 8 },
  { name: "fixed 15", fixed: 15 },
  { name: "depth only", want: (depth, inRate) => Math.ceil(depth / 100) },
  { name: "depth + in-rate", want: (depth, inRate) => Math.ceil(inRate / (0.8 * MU) + depth / 100) }];
function run(p) {
  let depth = 0, n = p.fixed || 2, maxDepth = 0, cost = 0, A = 0, D = 0, actions = 0;
  const starting = [], arrived = [], served = [];
  for (let t = 0; t < END; t++) {
    while (starting.length && starting[0] <= t) { starting.shift(); n++; }
    depth += RATE(t); A += RATE(t);
    const s = Math.min(depth, n * MU); depth -= s; D += s;
    arrived.push(A); served.push(D); maxDepth = Math.max(maxDepth, depth);
    cost += n + starting.length;                          // starting ones are paid too
    if (p.want && t % 30 === 0 && t >= 30) {
      const inRate = (A - arrived[t - 30]) / 30;          // measured, last 30 s
      const desired = Math.min(20, Math.max(2, p.want(depth, inRate))), total = n + starting.length;
      if (desired > total) { actions++; for (let k = total; k < desired; k++) starting.push(t + 60); }
      else if (desired < total && starting.length === 0) { actions++; n--; }
    }
  }
  let maxWait = 0, j = 0;                                 // FIFO: when is message #A(t) served?
  for (let t = 0; t < END; t++) { while (served[j] < arrived[t]) j++; maxWait = Math.max(maxWait, j - t); }
  return [p.name, maxDepth, maxWait + " s", (cost / 3600).toFixed(2), actions];
}
console.log("policy           max depth  max wait  consumer-hours  scale actions");
for (const p of POLICIES) {
  const r = run(p);
  console.log(r[0].padEnd(16) + String(r[1]).padStart(10) + r[2].padStart(10) + r[3].padStart(16) + String(r[4]).padStart(15));
}

policy           max depth  max wait  consumer-hours  scale actions
fixed 8              42000     525 s            8.00              0
fixed 15                 0       0 s           15.00              0
depth only           10790      72 s            8.52            102
depth + in-rate       7190      48 s            7.92             26

Dashboard-এ (পর্ব ৫০) রাখুন depth, সবচেয়ে পুরোনো বার্তার বয়স, আসা ও শেষ হওয়ার হার, redelivery-র হার আর DLQ depth. Alert দিন বয়সে — “সবচেয়ে পুরোনো বার্তা ৫ মিনিটের বেশি” — কারণ ব্যবহারকারী সংখ্যা নয়, দেরি টের পান।

Broker-এর উদাহরণ — কোনটি কেমন

Kafka-কেও প্রায়ই “queue” বলা হয়, কিন্তু তার মূল কাঠামো একটি টেকসই log, যেখানে পড়লে বার্তা মোছে না — সেই ভিন্নতা নিচের ছকে, আর পূর্ণ আলোচনা পর্ব ৩৩-এ। কোনো broker-এর সীমা বা ডিফল্ট সংস্করণভেদে বদলায়; অফিসিয়াল ডকুমেন্টেশন দেখুন।

Queue বনাম pub/sub বনাম log — একটি আগাম ছক

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

“অর্ডারের পরে SMS ধীর, কী করব?” — AI প্রায়ই বলে “Kafka বসান, Redis দিন, microservice-এ ভাগ করুন।” কিন্তু আসল প্রশ্ন থেকে যায়: বার্তা হারালে, দুবার এলে বা কখনো সফল না হলে কী হবে? সাধারণ ভুলগুলো:

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

• ভিড়ে জমা (λ − N·μ) × T, খালি হওয়ার সময় আর consumer-সংখ্যা নিজে আবার হিসাব করেছি
• Ack দেওয়া হয় কাজ commit হওয়ার পরে, আর visibility timeout স্বাভাবিক কাজের সবচেয়ে ধীর অংশের চেয়ে বড় (বা heartbeat আছে)
• Consumer idempotent: বার্তার id আর effect একই transaction-এ, বাইরের সেবায় idempotency key
• Retry-তে backoff আর jitter, max receive count, DLQ আর তার alert আছে
• ক্রমের দরকার কোথায় তা স্পষ্ট, আর message group বা version দিয়ে সমাধান করা
• একটি ছোট simulation বা load test চালিয়েছি, আর failure-mode পর্যালোচনা করেছি: producer, broker আর consumer — প্রত্যেকে মাঝপথে মরলে কী হয়
• পণ্যের প্রতিটি সীমা আর ডিফল্ট অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি