Delivery semantics — at-most-once, at-least-once, exactly-once আর idempotency

১ · একটি টাকা-যোগের বার্তা, তিন জায়গায় ভাঙন — কেন delivery কঠিন

একটি কাল্পনিক mobile wallet সেবার কথা ভাবুন। রিনা দোকানে ৫০০ টাকা ফেরত পাবেন। পেমেন্ট সার্ভিস একটি বার্তা পাঠায়: “wallet ৭-এ ৫০০ টাকা যোগ করুন”. Wallet সার্ভিস বার্তাটি পেয়ে টাকা যোগ করে, তারপর ফেরত জানায় “পেয়েছি” — একে বলে acknowledgement, ছোট করে ack. এই সাদামাটা আদানপ্রদানই পুরো পর্বের বিষয়।

বাস্তবে ভাঙন তিন জায়গায় হতে পারে:

1. বার্তা হারায়: network-এ packet হারায়, broker বা queue-এর সার্ভার পড়ে যায়। Wallet কিছুই জানে না।
2. Ack হারায়: টাকা যোগ হয়ে গেছে, কিন্তু “পেয়েছি” ফেরার পথে হারাল। প্রেরকের কাছে এটি প্রথম ঘটনার হুবহু মতো দেখায় — শুধু একটি timeout.
3. কাজ আর ack-এর মাঝে crash: Wallet সার্ভিস টাকা যোগ করল, ack পাঠানোর ঠিক আগে process মরে গেল। Broker ভাবে বার্তাটি প্রক্রিয়া হয়নি, তাই অন্য কাউকে আবার দেয়।

দ্বিতীয় আর তৃতীয় ঘটনায় কাজ হয়ে গেছে, অথচ প্রেরক বা broker তা জানে না। এর গভীরে আছে Two Generals’ Problem: হারাতে পারে এমন বার্তাপথে দুই পক্ষ কখনো নিশ্চিত হতে পারে না যে শেষ বার্তাটি পৌঁছেছে। গল্প আর ইতিহাস পর্ব ০৮-এর ভাবনার প্রশ্নে আছে; partial failure-এর পুরো ছবি আসবে পর্ব ৩৮-এ। এখানে আমরা দেখব ফলটা — নিচের stepper-এ “পরে” চাপুন:

২ · তিনটি নিশ্চয়তার সঠিক সংজ্ঞা — at-most-once, at-least-once, exactly-once

“কতবার পৌঁছাল” আর “কতবার কাজ হলো” — দুটি আলাদা প্রশ্ন। প্রতিটি বার্তা m-এর জন্য ধরুন k(m) = তার effect কতবার প্রয়োগ হলো (টাকা যোগ, ইমেইল, সারি লেখা)। তাহলে delivery semantics-এর তিনটি নিশ্চয়তা হলো:

খেয়াল করুন, প্রতিটি সংজ্ঞা effect নিয়ে, তার আসল শর্ত গ্রাহকের দিকে। At-least-once-এর শর্তটিও গুরুত্বপূর্ণ: প্রেরক নিজেই চিরতরে মরে গেলে বা retry-এর সীমা ফুরালে বার্তা হারাতে পারে — তাই বাস্তবে retry শেষ হলে বার্তা যায় একটি dead letter queue-তে (পর্ব ৩১)।

নিচের simulator-এ ১০০০টি wallet credit, প্রতিটি ১০০ টাকা। ধরা যাক network ১০% বার্তা আর ১০% ack হারায়। তিনটি কৌশলের ওপর একই seeded ক্ষতি চাপানো হয়েছে, যাতে তুলনা ন্যায্য হয়:

// Wallet credits over a lossy network: the SAME seeded faults for every strategy.
function mulberry32(a) { return () => { a |= 0; a = a + 0x6D2B79F5 | 0; let t = Math.imul(a ^ a >>> 15, 1 | a);
  t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t; return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const N = 1000, AMOUNT = 100, MAX_TRY = 8;   // assumed: 1000 credits of 100 taka, up to 8 attempts
const P_MSG = 0.10, P_ACK = 0.10;             // assumed: 10% of messages and 10% of acks are lost
const rnd = mulberry32(34), msgLost = [], ackLost = [];
for (let i = 0; i < N; i++) { msgLost.push([]); ackLost.push([]);
  for (let a = 0; a < MAX_TRY; a++) { msgLost[i].push(rnd() < P_MSG); ackLost[i].push(rnd() < P_ACK); } }

function run(name, retry, dedup) {
  let balance = 0, sends = 0, applied = 0, lost = 0, dups = 0;
  const seen = new Set();                     // the consumer's dedup store (message ids)
  for (let i = 0; i < N; i++) {
    let acked = false, count = 0;
    for (let a = 0; a < (retry ? MAX_TRY : 1) && !acked; a++) {
      sends++;
      if (msgLost[i][a]) continue;            // message never arrived; sender times out
      if (!(dedup && seen.has(i))) { balance += AMOUNT; count++; }
      seen.add(i);                            // a duplicate is still acked again
      if (!ackLost[i][a]) acked = true;       // ack lost -> sender cannot tell, so it retries
    }
    if (count === 0) lost++; else { applied++; dups += count - 1; }
  }
  const ok = balance === N * AMOUNT ? "CORRECT" : "WRONG";
  console.log(name.padEnd(22) + String(sends).padStart(6) + String(applied).padStart(8) +
    String(lost).padStart(6) + String(dups).padStart(6) + String(balance).padStart(9) + "  " + ok);
}
console.log("strategy               sends applied  lost  dups  balance  (expected " + N * AMOUNT + ")");
run("at-most-once", false, false);
run("at-least-once", true, false);
run("at-least-once + dedup", true, true);

strategy               sends applied  lost  dups  balance  (expected 100000)
at-most-once            1000     905    95     0    90500  WRONG
at-least-once           1231    1000     0   119   111900  WRONG
at-least-once + dedup   1231    1000     0     0   100000  CORRECT

সংখ্যাগুলো কি কাকতালীয়? ছোট একটি হিসাব

ধরুন বার্তা হারানোর সম্ভাবনা p_m, ack হারানোর p_a, আর retry-এর সীমা নেই। একটি চেষ্টা সফলভাবে শেষ হয় (বার্তা পৌঁছাল এবং ack ফিরল) q = (১ − p_m)(১ − p_a) সম্ভাবনায়। চেষ্টার সংখ্যা geometric, তাই গড়ে ১/qটি কপি পাঠানো হয়। যে চেষ্টা ব্যর্থ, তার মধ্যে বার্তা পৌঁছেছে কিন্তু ack হারিয়েছে এমনগুলোর ভাগ (১ − p_m)p_a / (১ − q). তাহলে প্রতি বার্তায় গড় duplicate:

মজার ফল: duplicate-এর হার বার্তা হারানোর ওপর নির্ভর করে না, শুধু ack হারানোর ওপর। p_a = ০.১ হলে প্রতি বার্তায় গড়ে ০.১১১টি duplicate — ১০০০টিতে প্রায় ১১১, simulator-এ ১১৯. পাঠানো কপি ১/০.৮১ ≈ ১.২৩৫ গুণ, অর্থাৎ প্রায় ১২৩৫, simulator-এ ১২৩১. At-most-once-এ প্রত্যাশিত ক্ষতি ১০০০ × ০.১ = ১০০, পাওয়া গেল ৯৫. বাস্তবে p_a অনেক ছোট, যেমন ০.০০১; কিন্তু সেকেন্ডে ১০,০০০ বার্তায় সেটিও প্রায় ১০টি duplicate প্রতি সেকেন্ডে — দিনে আট লাখের বেশি। বিরল ঘটনা বড় মাপে প্রতিদিনের ঘটনা।

৩ · “Exactly-once delivery” কেন অসম্ভব, আর effectively-once কেন সম্ভব

প্রশ্নটি ইন্টারভিউতে প্রায়ই আসে, আর উত্তর দুই স্তরে দিতে হয়। প্রথমে একটি ছোট প্রমাণ।

প্রমাণের ফাঁকটি লক্ষ করুন: “গ্রাহক কোনো স্মৃতি রাখবে না”. গ্রাহক যদি মনে রাখে “m-42 আগেই প্রয়োগ করেছি”, তাহলে প্রেরক নিশ্চিন্তে আবার পাঠাতে পারে। দ্বিতীয় কপি পৌঁছাবে, কিন্তু effect হবে না। একেই বলে effectively-once বা exactly-once processing:

শেষ শর্তটি বাদ দিলে পুরো কাঠামো ভেঙে পড়ে। চিহ্ন আগে লিখে effect-এর আগে crash হলে, retry-তে চিহ্ন দেখে কাজটি বাদ যাবে — effect হারাল। Effect আগে লিখে চিহ্নের আগে crash হলে, retry-তে চিহ্ন নেই — effect দুবার। তাই দুটি লেখা একই transaction-এ, যেমন একই ডেটাবেসে। এর বাস্তব রূপ পরের তিন অংশে।

৪ · Idempotent operation — SET বনাম INCR, version check আর শর্তসাপেক্ষ লেখা

সবচেয়ে সস্তা dedup হলো যেটি লাগেই না। কিছু কাজ নিজের স্বভাবেই idempotent: f(f(x)) = f(x). দুবার করলে একবারের মতোই ফল। একে বলে natural idempotency.

তাহলে কি সব INCR-কে SET বানিয়ে ফেলবেন — “balance = 1500”? সাবধান। Absolute মান নতুন একটি বিপদ আনে: পুরোনো বার্তা দেরিতে এলে নতুন মানকে মুছে দেয়। ধরুন “balance = 1500” আটকে ছিল, এর মধ্যে “balance = 1700” প্রয়োগ হয়েছে; তারপর পুরোনো বার্তার retry এলে balance ফিরে যায় ১৫০০-এ। একে লেখার ভাষায় বলে lost update.

প্রতিকার: প্রতিটি বার্তায় একটি version, আর লেখা হবে শর্তসাপেক্ষ — compare-and-set. “এই version আমার জানা version-এর চেয়ে নতুন হলে তবেই লিখুন।” এটি optimistic concurrency-এর বার্তা-সংস্করণ:

-- message: {order: 1001, status: 'SHIPPED', version: 3}
UPDATE orders SET status = 'SHIPPED', version = 3
WHERE id = 1001 AND version < 3;
-- 1 row changed  -> applied
-- 0 rows changed -> already have v3 or newer: a duplicate or a late message; ack and skip

এই নিয়মে duplicate আর দেরিতে আসা বার্তা দুটোই নিরাপদে বাদ যায়, কোনো আলাদা dedup টেবিল ছাড়াই। দাম: প্রেরককে প্রতিটি entity-র version জানতে হয়, যা সাধারণত সত্যের উৎস ডেটাবেস থেকেই আসে। লাইভ SQL-এ এই নিয়ম অংশ ৮-এ চালিয়ে দেখবেন।

৫ · Idempotency key আর dedup store — window, TTL আর মেমরির হিসাব

যে কাজ স্বভাবে idempotent নয়, সেখানে প্রতিটি বার্তাকে একটি অনন্য পরিচয় দিতে হয় — message id বা idempotency key. গ্রাহক একটি dedup store-এ মনে রাখে কোন id আগেই প্রক্রিয়া হয়েছে। ব্যাংকের কাউন্টারের টোকেনের মতো: একই টোকেন নম্বর দ্বিতীয়বার ডাকা হলে ক্যাশিয়ার খাতা দেখে বলেন, “এটার টাকা আগেই দিয়েছি।”

Key কে বানাবে, কী দিয়ে?

• অভিপ্রায়ের জন্মস্থানে: key বানাতে হয় যেখানে কাজটির জন্ম — রিনার ফেরতের অনুরোধ তৈরির মুহূর্তে, একটি UUID বা ব্যবসায়িক পরিচয় দিয়ে, যেমন “refund-for-order-1001”. প্রতিটি retry-তে সেই একই key. HTTP-র দিক পর্ব ০৮-এ।
• Broker-এর offset বা delivery tag key নয়: প্রেরক নিজে আবার publish করলে নতুন offset পায়, তাই একই কাজ দুটি ভিন্ন “id” পায়।
• Payload-এর hash সাবধানে: দুটি বৈধ, আলাদা ৫০০ টাকার ফেরত একই payload পেতে পারে। Hash তখনই চলে, যখন payload-এ আগে থেকেই অনন্য কিছু থাকে।

এবার নিচের stepper-এ সেই একই হারানো ack, কিন্তু wallet সার্ভিসের হাতে এখন একটি dedup store:

কতদিন মনে রাখবেন — window আর মেমরি

Dedup store চিরকাল বড় হতে পারে না, তাই প্রতিটি entry একটি TTL পায়। এই সময়কে বলে dedup window. নিয়ম একটাই: window অবশ্যই সবচেয়ে পুরোনো সম্ভাব্য duplicate-এর বয়সের চেয়ে বড় হতে হবে। শুধু retry-এর সময়সূচি নয়, গ্রাহকের দীর্ঘ বিভ্রাট, dead letter queue থেকে আবার পাঠানো (redrive) আর পুরোনো offset থেকে replay — সব গুনতে হয়। আর মেমরির সূত্র:

// Dedup store sizing: how long must message ids be remembered, and what does it cost?
const RATE = 2000;           // assumed: 2,000 messages/s at peak, every one with a unique id
const BYTES = 100;           // assumed: ~100 B per entry (16 B id + expiry + store overhead)
const REPLICAS = 2;          // assumed: the store keeps 2 copies
// Ages at which a duplicate of an already-processed message can still arrive (assumed):
let retry = 0; for (let k = 0; k < 10; k++) retry += 2 ** k;        // backoff 1,2,4..512 s
const sources = [
  ["retry", retry],               // producer and broker retries: 1023 s, about 17 min
  ["lag", 6 * 3600],              // consumer down for 6 h, then catches up
  ["redrive", 2 * 86400],         // dead-letter messages re-sent 2 days later
  ["replay", 3 * 86400],          // offsets reset to 3 days ago
];
const human = (s) => s < 3600 ? (s / 60).toFixed(0) + " min" : s < 86400 ? (s / 3600).toFixed(0) + " h" : (s / 86400).toFixed(0) + " d";
const size = (b) => b >= 1e9 ? (b / 1e9).toFixed(2) + " GB" : (b / 1e6).toFixed(0) + " MB";
console.log("retry schedule ends after " + retry + " s (" + human(retry) + ")\n");
console.log("window   keys stored      memory x" + REPLICAS + "    duplicates still caught");
for (const w of [5 * 60, 3600, 86400, 7 * 86400]) {
  const keys = RATE * w, mem = keys * BYTES * REPLICAS;
  const caught = sources.filter(([, age]) => age <= w).map(([n]) => n);
  console.log(human(w).padEnd(8) + String(keys.toLocaleString("en-US")).padStart(13) +
    size(mem).padStart(14) + "    " + (caught.join(", ") || "none"));
}
// Alternative: remember only the highest sequence number per (producer, partition).
const PRODUCERS = 400, PARTITIONS = 48, SEQ_BYTES = 32;            // assumed
console.log("\nper-producer sequence table: " + (PRODUCERS * PARTITIONS).toLocaleString("en-US") +
  " rows, about " + (PRODUCERS * PARTITIONS * SEQ_BYTES / 1e3).toFixed(0) + " KB, independent of the window");

retry schedule ends after 1023 s (17 min)

window   keys stored      memory x2    duplicates still caught
5 min         600,000        120 MB    none
1 h         7,200,000       1.44 GB    retry
1 d       172,800,000      34.56 GB    retry, lag
7 d     1,209,600,000     241.92 GB    retry, lag, redrive, replay

per-producer sequence table: 19,200 rows, about 614 KB, independent of the window

• Window ছোট রাখার উপায়: replay-এর সময় ব্যবসায়িক key-এর version check (অংশ ৪) চালু রাখা, যাতে dedup store-এর বাইরের পুরোনো বার্তাও নিরাপদ থাকে।
• Bloom filter দিয়ে মেমরি বাঁচানো? এতে false positive মানে একটি নতুন বার্তাকে duplicate ভেবে ফেলে দেওয়া — অর্থাৎ ক্ষতি। শুধু দ্রুত প্রাথমিক যাচাইয়ে চলে, চূড়ান্ত সিদ্ধান্তে নয় (পর্ব ৪৫, ভাবনার প্রশ্ন ৩)।
• Dedup store আর ডেটাবেস আলাদা হলে: Redis-এ চিহ্ন আর PostgreSQL-এ টাকা — দুটি আলাদা লেখা, আবার সেই অংশ ৩-এর crash-এর ফাঁক। তাই টাকার মতো effect-এ চিহ্নটি একই ডেটাবেসে রাখাই নিরাপদ। পরের অংশ ঠিক এটাই।

৬ · Inbox pattern আর transactional consumer — effect, চিহ্ন আর offset এক transaction-এ

Inbox pattern-এ dedup store হলো গ্রাহকের নিজের ডেটাবেসের একটি টেবিল, যার message_id-তে UNIQUE constraint. প্রতিটি বার্তায় একটি local transaction: inbox-এ সারি, তারপর effect, তারপর COMMIT. Duplicate এলে insert-এ ০টি সারি — effect বাদ। পর্ব ২৫-এ outbox-এর অপর প্রান্তে এই idempotent consumer দেখেছেন; এখানে আমরা তার ভেতরটা খুলব।

লাইভ SQL-এ handler-টি চালিয়ে দেখুন। wallets-এ রিনার wallet ৭, balance ১০০০; inbox-এ message_id অনন্য। SQLite-এর changes() আগের বাক্যে কয়টি সারি বদলেছে তা দেয়: ১ মানে নতুন বার্তা, ০ মানে duplicate:

-- Credit handler for one message: the inbox row and the credit commit TOGETHER.
-- Delivery 1 of m-42 (credit 500 taka to wallet 7):
BEGIN;
INSERT OR IGNORE INTO inbox VALUES ('m-42', 7, 500, '10:00:01');
-- changes() = rows the INSERT just above added: 1 = new message, 0 = duplicate.
UPDATE wallets SET balance = balance + 500 WHERE id = 7 AND changes() = 1;
COMMIT;
SELECT balance FROM wallets WHERE id = 7;
-- The ack was lost, so the broker delivers m-42 AGAIN. Same handler, same statements:
BEGIN;
INSERT OR IGNORE INTO inbox VALUES ('m-42', 7, 500, '10:00:31');
UPDATE wallets SET balance = balance + 500 WHERE id = 7 AND changes() = 1;
COMMIT;
SELECT balance FROM wallets WHERE id = 7;
-- A new message m-43 (credit 200) is applied normally:
BEGIN;
INSERT OR IGNORE INTO inbox VALUES ('m-43', 7, 200, '10:00:40');
UPDATE wallets SET balance = balance + 200 WHERE id = 7 AND changes() = 1;
COMMIT;
SELECT w.balance, (SELECT count(*) FROM inbox) AS inbox_rows,
       (SELECT first_seen FROM inbox WHERE message_id = 'm-42') AS m42_first_seen
FROM wallets w WHERE w.id = 7;

Offset-ও একই transaction-এ — transactional consumer

Log-ভিত্তিক broker-এ (Kafka-ধাঁচের) গ্রাহক নিজে মনে রাখে কোথা পর্যন্ত পড়েছে — partition-এর offset; consumer group আর offset-এর বিস্তারিত পর্ব ৩৩-এ। প্রশ্ন হলো, offset কখন commit করবেন? নিচের stepper-এ crash-এর ফাঁকটি দেখুন (Kafka-র রীতিতে committed offset মানে “এরপর এটি পড়ব”):

আরও এক ধাপ এগোনো যায়। Offset-টিকেই যদি ডেটাবেসের একটি টেবিলে (যেমন consumer_offsets) effect-এর সাথে একই transaction-এ লেখেন, আর চালু হওয়ার সময় broker-এর বদলে সেখান থেকে offset পড়েন, তাহলে সেই partition-এর জন্য আলাদা inbox-ও লাগে না: একটি partition-এ offset নিজেই একটি বাড়তে থাকা sequence number (মাঝে ফাঁক থাকলেও ক্ষতি নেই, কারণ রাখা হয় “পরের offset”). একে বলে transactional consumer — consume, effect আর offset commit একসাথে, অবিভাজ্যভাবে। শর্ত: effect আর offset একই ডেটাবেসে; আর অন্য পথে আসা duplicate (যেমন প্রেরক নিজে দুবার publish করলে, দুটি ভিন্ন offset-এ) ধরতে message_id-এর inbox তবুও লাগে।

৭ · Kafka-ধাঁচের idempotent producer আর transaction — আর end-to-end-এর শিকল

এতক্ষণ duplicate ঠেকিয়েছি গ্রাহকের দিকে। প্রেরক থেকে broker-এর পথেও একই সমস্যা: producer batch পাঠাল, broker লিখল, ack হারাল, producer আবার পাঠাল — log-এ একই বার্তা দুটি offset-এ। Kafka ২০১৭ সালে (সংস্করণ 0.11, KIP-98 প্রস্তাব) এর জন্য দুটি ব্যবস্থা আনে। খুঁটিনাটি সংস্করণভেদে আলাদা, তাই নিচের বর্ণনা ধারণার স্তরে:

• Idempotent producer: broker প্রতিটি producer-কে একটি producer ID (PID) দেয়। প্রতিটি partition-এ producer-এর প্রতিটি batch একটি বাড়তে থাকা sequence number বহন করে। Broker প্রতিটি (PID, partition)-এর শেষ sequence মনে রাখে; একই বা পুরোনো নম্বর এলে আবার লেখে না, শুধু সফল উত্তর দেয়; ফাঁক থাকলে প্রত্যাখ্যান করে। এটি অংশ ৫-এর “per-producer sequence” কৌশল — মেমরি সামান্য।
• Transaction: একটি স্থির transactional.id দিয়ে producer কয়েকটি partition-এ লেখা আর consumer offset একসাথে commit বা abort করতে পারে। নতুন instance চালু হলে একটি epoch বাড়ে, আর পুরোনো epoch-এর “zombie” producer-এর লেখা প্রত্যাখ্যাত হয় — fencing token-এর একই ধারণা (পর্ব ৪৩)।
• read_committed: consumer-এর isolation.level=read_committed হলে সে শুধু commit হওয়া transaction-এর বার্তা দেখে; abort হওয়াগুলো বাদ যায়। লেখার সময়ে ডিফল্ট read_uncommitted. এটি ডেটাবেসের READ COMMITTED isolation level থেকে আলাদা জিনিস, নাম মিললেও।

# producer
enable.idempotence=true          # PID + per-partition sequence numbers
acks=all                         # required for idempotence
transactional.id=wallet-proc-3   # stable across restarts; enables fencing
# consumer
isolation.level=read_committed   # skip messages of aborted transactions
enable.auto.commit=false         # offsets go inside the transaction instead
# loop: poll -> beginTransaction -> send results -> sendOffsetsToTransaction -> commitTransaction

সীমা: শিকলের প্রতিটি কড়া

এই ব্যবস্থার নিশ্চয়তা Kafka থেকে পড়া, প্রক্রিয়া, Kafka-তে লেখা পর্যন্ত। আপনার consumer যদি PostgreSQL-এ টাকা লেখে বা email পাঠায়, সেই লেখা Kafka-র transaction-এর অংশ নয়। সেখানে আবার অংশ ৬-এর inbox বা transactional consumer লাগে। পুরো পথটি একটি শিকল:

Stream processing framework-গুলোও (যেমন Flink বা Kafka Streams) “exactly-once” দেয় নিজেদের state আর সমর্থিত sink-এর ভেতরে — checkpoint আর transactional লেখা দিয়ে; তার বিবরণ পর্ব ৩৬-এ।

৮ · ক্রমের নিশ্চয়তা — key আর partition, আগে-পরে আসা বার্তা আর sequence number

“কতবার” প্রশ্নের পাশে আরেকটি প্রশ্ন: “কোন ক্রমে?” ফেরিঘাটের সিরিয়ালের মতো: একটি লাইনে গাড়ি ক্রমেই ওঠে, কিন্তু দুটি ঘাটের দুই লাইনের মধ্যে কে আগে পার হবে, তার কোনো নিশ্চয়তা নেই। Broker-এও তাই:

• Per-key ordering: Kafka-ধাঁচের log ক্রম দেয় শুধু একটি partition-এর ভেতরে। একই key (যেমন wallet_id) সবসময় একই partition-এ যায়, তাই একই wallet-এর বার্তা ক্রমে আসে; দুই wallet-এর মধ্যে ক্রমের প্রতিশ্রুতি নেই (পর্ব ৩৩)। Partition key বাছাইয়ের যুক্তি পর্ব ২৩-এর মতোই।
• Retry ক্রম উল্টাতে পারে: batch ১ ব্যর্থ, batch ২ সফল, তারপর batch ১-এর retry — log-এ ২, ১. Idempotent producer-এর sequence check এটি ঠেকায় (stepper-এর শেষ ধাপ)।
• কয়েকজন গ্রাহক বা thread: সাধারণ queue-তে (পর্ব ৩১) কয়েকজন গ্রাহক সমান্তরালে নিলে, বা একজন গ্রাহক partition-এর বার্তা কয়েকটি thread-এ ছড়ালে, ক্রম যায়।
• সবকিছুর এক ক্রম (total order) দামি: সব বার্তা একটি partition-এ মানে একজন গ্রাহক, তাই throughput একটি যন্ত্রের সমান। বহু যন্ত্রে total order লাগলে consensus লাগে (পর্ব ৪২)।

তাই গ্রাহককে নিজে আগে-পরে আসা বার্তা সামলাতে হয়, প্রতিটি entity-র জন্য একটি version বা sequence number দিয়ে। বার্তার ধরন অনুযায়ী নিয়ম দুটি: absolute অবস্থা (“অর্ডার এখন SHIPPED, version 3”) হলে নতুনতর এলে লিখুন, পুরোনো বা সমান বাদ দিন। পরিবর্তন (“৫০ পয়েন্ট যোগ, seq 1”) হলে ঠিক পরের নম্বরটিই লিখুন; আগাম এলে অপেক্ষার তালিকায় রাখুন, পুরোনো এলে বাদ দিন। লাইভ SQL-এ দুটিই:

-- (a) Absolute state ("status is X as of version v"): apply only if NEWER than what we have.
UPDATE orders SET status = 'SHIPPED', version = 3 WHERE id = 1001 AND version < 3;
UPDATE orders SET status = 'PAID', version = 2 WHERE id = 1001 AND version < 2;   -- late v2
UPDATE orders SET status = 'SHIPPED', version = 3 WHERE id = 1001 AND version < 3; -- duplicate v3
SELECT id, status, version FROM orders;
-- (b) Deltas ("add 50 points", seq per customer): apply only the NEXT seq, in order.
UPDATE points SET total = total + 50, last_seq = 1 WHERE customer = 55 AND last_seq = 0;
UPDATE points SET total = total + 30, last_seq = 3 WHERE customer = 55 AND last_seq = 2; -- early seq 3
UPDATE points SET total = total + 20, last_seq = 2 WHERE customer = 55 AND last_seq = 1;
UPDATE points SET total = total + 30, last_seq = 3 WHERE customer = 55 AND last_seq = 2; -- seq 3 again
UPDATE points SET total = total + 20, last_seq = 2 WHERE customer = 55 AND last_seq = 1; -- duplicate seq 2
SELECT customer, total, last_seq FROM points;

আগাম বার্তা আটকে রাখার দামও আছে: পরের নম্বরটি না এলে পেছনের সব আটকে থাকে — head-of-line blocking. তাই অপেক্ষার একটি সময়সীমা আর তারপর সতর্কবার্তা বা হাতে মীমাংসা রাখুন। ক্রম আর সময়ের তাত্ত্বিক দিক (Lamport clock, vector clock) আসবে পর্ব ৩৯-এ, chat-এর বার্তার ক্রম পর্ব ৫৫-এ।

৯ · নিয়ন্ত্রণের বাইরের side effect — email, SMS, payment, আর কখন at-most-once ভালো

Inbox কাজ করে, কারণ চিহ্ন আর effect একই ডেটাবেসে। কিন্তু কিছু side effect আপনার ডেটাবেসে ঘটে না: SMS gateway-তে বার্তা, email, ব্যাংক বা payment provider-এ টাকা কাটা। সেগুলো আপনার transaction-এ বাঁধা যায় না। SMS পাঠানোর পর আর inbox-এর commit-এর আগে crash হলে retry-তে আরেকটি SMS যাবে।

যখন duplicate হারানোর চেয়েও খারাপ

সব জায়গায় at-least-once ভালো নয়। কয়েকটি ক্ষেত্রে at-most-once-ই সৎ পছন্দ:

• শিগগিরই পুরোনো হয়ে যাওয়া তথ্য: ride-sharing অ্যাপে চালকের অবস্থান প্রতি কয়েক সেকেন্ডে আসে। একটি হারালে পরেরটি আসছে; পুরোনো অবস্থানের দেরিতে retry বরং মানচিত্রে গাড়িকে পেছনে নিয়ে যায়।
• উল্টানো যায় না এমন ভৌত কাজ: ATM-এর টাকা বের করা, দরজার তালা খোলা। দুবার টাকা বের হওয়ার চেয়ে একবারও না হওয়া, তারপর হিসাব মিলিয়ে ফেরত দেওয়া, অনেক নিরাপদ।
• বিরক্তিকর বা ক্ষতিকর বার্তা: “আপনার রাইড এসে গেছে” দেরিতে দ্বিতীয়বার আসা অর্থহীন; ভুল সময়ের একটি push notification বিশ্বাস নষ্ট করে।
• হিসাবি telemetry: click বা metric-এর নমুনায় সামান্য ক্ষতি চলে, কিন্তু duplicate-এর জন্য dedup store-এর খরচ বেশি।

At-most-once বেছে নিলেও হারানো ধরা আর মেটানোর পথ রাখুন: ATM-এর ক্ষেত্রে মুদি দোকানের খাতার মতো দিনশেষের মিলানো, অবস্থানের ক্ষেত্রে পরের আপডেট।

১০ · AI-এর যুগে delivery semantics যাচাই

“বার্তা যেন দুবার প্রক্রিয়া না হয়, কী করব?” — AI প্রায়ই উত্তর দেয়, “Kafka-র exactly-once চালু করুন।” কথাটি আংশিক সত্য, কিন্তু আপনার ডেটাবেস আর SMS gateway সেই নিশ্চয়তার বাইরে। চেনা ভুলগুলো:

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

• প্রতিটি effect-এর জন্য লিখেছি: হারালে ক্ষতি কী, দুবার হলে ক্ষতি কী
• Ack আর offset commit effect-এর পরে; auto-commit-এর আচরণ যাচাই করেছি
• Dedup চিহ্ন আর effect একই transaction-এ; duplicate-কেও ack করা হয়
• Dedup window আর মেমরি নিজে হিসাব করেছি; replay-তে version check আছে
• বাইরের provider-এ idempotency key বা reconciliation-এর পথ আছে
• Crash আর ack হারানো simulator বা পরীক্ষায় চালিয়েছি; পণ্যের দাবি ডকুমেন্টেশনে মিলিয়েছি