Distributed transaction — two-phase commit, saga আর outbox pattern

১ · একটি কাজ, তিনটি ডেটাবেস — যেখানে একটি ACID transaction আর নেই

ঈদের আগের রাত। একটি অনলাইন বাস-টিকিট সেবায় (কাল্পনিক) রুমানা ঢাকা–রাজশাহী রুটের ট্রিপ ৭-এর সিট A3 বেছে “৮৫০ টাকা পরিশোধ করুন” চাপলেন। তাঁর কাছে এটি একটি কাজ; সেবার ভেতরে তিন টুকরো, তিনটি সেবায়:

• সিট সার্ভিস — নিজের seats ডেটাবেসে A3 আটকে রাখে।
• পেমেন্ট সার্ভিস — নিজের wallet ডেটাবেস থেকে ৮৫০ টাকা কাটে।
• টিকিট সার্ভিস — বাস অপারেটরের সিস্টেম থেকে টিকিট নম্বর এনে নিজের tickets ডেটাবেসে লেখে।

প্রতিটি সেবার নিজস্ব ডেটাবেস — database-per-service নীতি, যা microservices-এ প্রচলিত (পর্ব ৪৭)। কেউ অন্যের টেবিলে সরাসরি লেখে না, কথা হয় API বা বার্তায়; তাই প্রতিটি দল স্বাধীনভাবে বদলাতে আর scale করতে পারে। দামটা দেখা যায় ঠিক এখানে।

একটি ডেটাবেস হলে কাজটি সহজ ছিল (পর্ব ২৪): BEGIN, তিনটি লেখা, COMMIT — transaction-এর ACID নিশ্চয়তায় তিনটিই হবে, নয়তো একটিও না, আর মাঝের অবস্থা কেউ দেখবে না। এখন তিনটি আলাদা commit; মাঝপথে থামলে:

শেষ দুটি সারি এই কোর্সের পরিচিত শত্রু partial failure: উত্তর না আসা দেখে বলা যায় না ওপারে কী ঘটেছে — timeout মানে “জানি না”, “হয়নি” নয়। একটি অনুরোধের জন্য সমাধান পর্ব ০৮-এ দেখেছেন (idempotency key); এবার কয়েকটি সেবা জুড়ে একটি পুরো কাজের পালা।

কেন একটি ACID transaction আর সম্ভব নয়

এক ডেটাবেসে atomicity আসে একটি সরল কৌশল থেকে: সব পরিবর্তন আগে write-ahead log-এ (WAL), শেষে একটি COMMIT record ডিস্কে fsync. ওই record টেকসই হওয়ার মুহূর্তটিই সিদ্ধান্ত; crash-এর পর log পড়ে সব আবার করা হয়, নয়তো সব বাতিল (পর্ব ১৯-এর storage engine, DBMS কোর্সের recovery পর্ব)। Isolation দেয় একটি lock manager বা MVCC (পর্ব ২৪)।

তিনটি ডেটাবেসে তিনটি log, তিনটি lock manager — এমন কোনো একক record নেই, যা তিনজনের ভাগ্য একসাথে ঠিক করে। সামনে চারটি পথ:

২ · Two-phase commit — prepare, ভোট আর একটি commit point

Two-phase commit (2PC) একটি atomic commit প্রোটোকল: কয়েকটি স্বাধীন ডেটাবেস একটিই সিদ্ধান্ত নেয় — সবাই commit, নয়তো সবাই abort. চরিত্র দুটি: একজন coordinator (প্রায়ই transaction manager নামের লাইব্রেরি বা সেবা), আর কয়েকজন participant — এখানে seats, wallet আর tickets ডেটাবেস।

চারটি ধাপ

1. কাজ (execution). লেনদেনের global id ধরা যাক T42. প্রতিটি participant নিজের অংশ করে — A3 বিক্রি, wallet −৮৫০, টিকিটের খসড়া — আর lock ধরে রাখে, commit করে না।
2. ধাপ ১ — prepare (ভোট). Coordinator সবাইকে PREPARE পাঠায়: “নিশ্চিতভাবে commit পারবেন?” Participant নিয়ম যাচাই করে, পরিবর্তন আর একটি PREPARED record log-এ লিখে fsync করে — forced log write — তারপর YES. না পারলে NO বলে সঙ্গে সঙ্গে নিজে abort করে।
3. সিদ্ধান্ত। সব YES এলে coordinator নিজের log-এ COMMIT record লিখে fsync করে; এটি টেকসই হওয়ার মুহূর্তটিই commit point. একটিও NO, বা সময়মতো ভোট না এলে, সিদ্ধান্ত ABORT.
4. ধাপ ২ — commit (খবর). Coordinator সিদ্ধান্ত পাঠায়; participant নিজের COMMIT বা ABORT record force করে, lock ছাড়ে, ACK দেয়। সব ACK এলে coordinator force ছাড়াই END লেখে আর লেনদেনটি ভুলে যায়।

দুটি প্রতিশ্রুতিতেই প্রোটোকল দাঁড়িয়ে। Participant-এর: “YES মানে crash হলেও commit করতে পারব, নিজে abort করব না।” Coordinator-এর: “সিদ্ধান্ত আগে log-এ, তারপর জানানো।” YES থেকে সিদ্ধান্ত পর্যন্ত participant-এর অবস্থা prepared — commit-ও নয়, abort-ও নয়।

নিচে সময়সহ পুরো পথ। ধরা যাক coordinator আর প্রতিটি participant-এর RTT ১ ms (একই data centre, একমুখী পথ ০.৫ ms), একটি fsync ২ ms, আর তিন participant সমান্তরালে কাজ করে। “পরে” চাপুন:

কে কোন record লেখে, আর crash-এর পর কী করে

Restart-এর পর প্রত্যেকে log পড়ে ঠিক করে। Participant-এর log-এ PREPARED না থাকলে সে নিজে abort করে — তার YES ছাড়া কেউ commit করতে পারত না। PREPARED আছে কিন্তু সিদ্ধান্ত নেই, তাহলে লেনদেনটি in-doubt: সে lock আবার ধরে coordinator-কে জিজ্ঞেস করে অপেক্ষা করে। সিদ্ধান্ত থাকলে সেই অনুযায়ী redo বা undo. Coordinator-এর log-এ সিদ্ধান্ত থাকলে সে আবার পাঠায়, না থাকলে ABORT — কারণ COMMIT না লিখে সে কাউকে COMMIT বলে না।

বাস্তবে — XA আর ডেটাবেসের prepare কমান্ড

বাস্তবে 2PC প্রায়ই চলে XA interface দিয়ে: transaction manager coordinator, আর ডেটাবেস বা কিছু broker participant (“resource manager”). MySQL-এর InnoDB-তে XA কমান্ড আছে; PostgreSQL-এর নিজস্ব PREPARE TRANSACTION আর COMMIT PREPARED ডিফল্টে বন্ধ থাকে (max_prepared_transactions = 0; উদাহরণ DBMS কোর্সের distributed database পর্বে)। MySQL-এ একটি participant-এর ধাপ:

XA START 't42';
UPDATE seats SET state = 'SOLD', booking = 't42'
WHERE trip_id = 7 AND seat = 'A3';
XA END 't42';
XA PREPARE 't42';     -- vote YES: changes are durable, locks are still held
-- ... the coordinator decides ...
XA COMMIT 't42';      -- or: XA ROLLBACK 't42'
XA RECOVER;           -- after a crash: list prepared (in-doubt) transactions

৩ · Coordinator মরলে — in-doubt participant আর blocking

2PC-এর বিপদ ধাপ ১ আর ২-এর মাঝখানে। YES দিয়েছে বলে participant নিজে abort পারে না, সিদ্ধান্ত পায়নি বলে commit-ও না। এই সময়ে coordinator crash করলে বা network ভাগ হলে সে শুধু অপেক্ষা করতে পারে — lock ধরে। তাই 2PC একটি blocking protocol.

নিচে সবচেয়ে খারাপ মুহূর্তের crash: COMMIT লেখার ঠিক পরে, পাঠানোর আগে। ধরা যাক ঈদের ভিড়ে ট্রিপ ৭-এ সেকেন্ডে ২০টি বুকিংয়ের চেষ্টা আসে, আর সবাইকে ট্রিপের সিট-গণনার একই সারি বদলাতে হয় — যা এখন T42-এর lock-এ।

কেন participant-রা নিজেরা সিদ্ধান্ত নিতে পারে না — একটি ছোট প্রমাণ

মনে হতে পারে, “সবাই তো YES দিয়েছে; তাহলে commit করে ফেললেই হয়।” দুটি সম্ভাব্য ইতিহাস ভাবুন:

• ইতিহাস ক: সব YES পেয়ে coordinator COMMIT লিখল, তারপর crash করল।
• ইতিহাস খ: একটি YES পৌঁছাতে দেরি হওয়ায় coordinator-এর নিজের timeout বাজল; সে ABORT লিখল (যা নিয়মসম্মত), তারপর crash করল। অথবা ঠিক তখনই গ্রাহক নিজে “বাতিল” চাপলেন।

দুই ইতিহাসেই তিন participant-এর অবস্থা হুবহু এক — PREPARED, কোনো বার্তা নেই। তাই তাদের যেকোনো নিয়ম — “সবাই PREPARED হলে commit” বা “abort” — দুই ইতিহাসে একই কাজ করবে, আর একটিতে ভুল হবেই: ক-তে abort করলে coordinator ফিরে বলবে COMMIT, খ-তে commit করলে বলবে ABORT. Atomicity বাঁচানোর একমাত্র নিরাপদ পথ অপেক্ষা। এটি বাস্তবায়নের দুর্বলতা নয়, প্রোটোকলের গঠনের ফল: সিদ্ধান্ত একটি যন্ত্রের ডিস্কে, আর সেটি নাগালের বাইরে।

বাস্তবের ক্ষতি আর “heuristic” সিদ্ধান্ত

In-doubt লেনদেন restart-এর পরেও টিকে থাকে, কারণ YES-এর প্রতিশ্রুতি ডিস্কে লেখা; ভুলে যাওয়া prepared লেনদেন দিনের পর দিন lock ধরে রাখতে পারে, PostgreSQL-এ পুরোনো সারি পরিষ্কারের কাজও (vacuum) আটকায়। দীর্ঘ বিভ্রাটে অপারেটর হাতে commit বা rollback করতে পারেন — XA-র ভাষায় heuristic decision; lock মুক্ত হয়, কিন্তু সিদ্ধান্ত coordinator-এর উল্টো হলে atomicity ভাঙে। তাই prepared লেনদেনের সংখ্যা আর বয়স monitor করুন।

Simulator-এ চারটি পরিস্থিতি — সব YES, একজনের NO, সিদ্ধান্তের আগে আর পরে crash — মৌলিক 2PC-তে (সিদ্ধান্ত আর PREPARED দুটোই force, সবার ACK). একমুখী পথ ০.৫ ms, fsync ২ ms, বিভ্রাট ৩০ সেকেন্ড — সবই ধরে নেওয়া মান:

// Basic two-phase commit: coordinator C + 3 participants. Time in ms, no randomness.
const HOP = 0.5, FSYNC = 2, DOWN = 30000;    // assumed: one-way delay, one forced log write, C outage
const P = ["seats", "wallet", "tickets"];
const ms = (x) => x.toFixed(1);

function run(title, votes, crash) {          // crash: none | "before-decision" | "after-decision"
  console.log("--- " + title);
  const yes = votes.filter(Boolean).length;
  let decision = yes === P.length ? "COMMIT" : "ABORT";
  let tSend = HOP + FSYNC + HOP + FSYNC;     // PREPARE out, vote forced, vote back, decision forced
  if (crash === "before-decision") { decision = "ABORT"; tSend = 1 + DOWN + FSYNC; }
  if (crash === "after-decision") tSend += DOWN;          // COMMIT is on C's disk, but C is down
  console.log("votes: " + P.map((p, i) => p + "=" + (votes[i] ? "YES" : "NO")).join(" ") +
    (crash === "before-decision" ? "  (C crashed at t=1.0, votes lost)" : ""));
  votes.forEach((v, i) => { if (!v) console.log(P[i] + " voted NO: aborts at once, locks freed at t=0.5"); });
  if (crash) {
    console.log("t=10000.0 all participants: PREPARED, no decision, peers know nothing -> BLOCKED");
    console.log("C back at t=" + ms(tSend - (crash === "after-decision" ? 0 : FSYNC)) + ", reads log: " +
      (decision === "COMMIT" ? "COMMIT found" : "no decision -> ABORT (nobody can have committed)"));
  }
  const tFree = tSend + HOP + FSYNC;          // decision arrives, participant forces it, frees locks
  console.log("C sends " + decision + " at t=" + ms(tSend) + "; YES voters free locks at t=" +
    ms(tFree) + " (held " + ms(tFree - HOP) + " ms after PREPARE)");
  console.log("ACKs in at t=" + ms(tFree + HOP) + "; messages=" + (2 * P.length + 2 * yes) +
    ", forced log writes=" + (1 + 2 * yes));
  return tFree - HOP;
}
const hold = run("A: all vote YES", [true, true, true]);
run("B: wallet votes NO (balance too low)", [true, false, true]);
run("C: C crashes after sending PREPARE", [true, true, true], "before-decision");
const frozen = run("D: C crashes right after forcing COMMIT", [true, true, true], "after-decision");
console.log("hot seat row: at most " + Math.floor(1000 / hold) + " commits/s with " + ms(hold) +
  " ms locks; in D it is frozen for " + (frozen / 1000).toFixed(1) + " s");

--- A: all vote YES
votes: seats=YES wallet=YES tickets=YES
C sends COMMIT at t=5.0; YES voters free locks at t=7.5 (held 7.0 ms after PREPARE)
ACKs in at t=8.0; messages=12, forced log writes=7
--- B: wallet votes NO (balance too low)
votes: seats=YES wallet=NO tickets=YES
wallet voted NO: aborts at once, locks freed at t=0.5
C sends ABORT at t=5.0; YES voters free locks at t=7.5 (held 7.0 ms after PREPARE)
ACKs in at t=8.0; messages=10, forced log writes=5
--- C: C crashes after sending PREPARE
votes: seats=YES wallet=YES tickets=YES  (C crashed at t=1.0, votes lost)
t=10000.0 all participants: PREPARED, no decision, peers know nothing -> BLOCKED
C back at t=30001.0, reads log: no decision -> ABORT (nobody can have committed)
C sends ABORT at t=30003.0; YES voters free locks at t=30005.5 (held 30005.0 ms after PREPARE)
ACKs in at t=30006.0; messages=12, forced log writes=7
--- D: C crashes right after forcing COMMIT
votes: seats=YES wallet=YES tickets=YES
t=10000.0 all participants: PREPARED, no decision, peers know nothing -> BLOCKED
C back at t=30005.0, reads log: COMMIT found
C sends COMMIT at t=30005.0; YES voters free locks at t=30007.5 (held 30007.0 ms after PREPARE)
ACKs in at t=30008.0; messages=12, forced log writes=7
hot seat row: at most 142 commits/s with 7.0 ms locks; in D it is frozen for 30.0 s

৪ · 2PC-এর দাম — latency, lock, throughput আর availability-র হিসাব

Stepper-এর সংখ্যাগুলো এবার সূত্রে বাঁধা যাক। ধরা যাক coordinator থেকে প্রতিটি participant-এর round trip = r, একটি forced log write = f, participant N জন, আর তারা সমান্তরালে কাজ করে — তাই প্রতিটি ধাপে সবচেয়ে ধীরজনের সময়ই গোনা হয়।

1. Commit point পর্যন্ত: PREPARE যাওয়া (r/২) + PREPARED force (f) + YES ফেরা (r/২) + সিদ্ধান্ত force (f) = r + ২f. গ্রাহককে “নিশ্চিত” বলা যায় এর পরেই।
2. Participant-এর lock, PREPARE পাওয়া থেকে: f + r/২ + f + r/২ + f = r + ৩f. এর আগের execution-এর সময়ও lock ধরা থাকে, তাই এটি নিম্নসীমা।
3. পুরো প্রোটোকল, END পর্যন্ত: ২r + ৩f.
4. বার্তা আর forced write: প্রতিজনের সাথে PREPARE, ভোট, সিদ্ধান্ত আর ACK — ৪Nটি বার্তা; প্রতিজনের দুটি আর coordinator-এর একটি — ২N + ১টি forced write.

শেষ সারিটিই আসল শিক্ষা। Hot row — যে সারি প্রায় প্রতিটি লেনদেন বদলায়, যেমন ঈদের জনপ্রিয় ট্রিপের সিট-গণনা। Lock না ছাড়া পর্যন্ত পরের লেনদেন দাঁড়িয়ে থাকে, তাই সেখানে সেকেন্ডে বড়জোর ১০০০ ÷ (lock-এর ms)টি লেনদেন — যত সার্ভারই যোগ করুন। এই সীমা latency-র চেয়েও বড় দাম (Little-এর সূত্র, পর্ব ০৪); দুই region-এর আসল RTT-র হিসাব পর্ব ০৭-এ।

সবচেয়ে ধীরজন আর সবচেয়ে দুর্বলজন

সমান্তরাল হলেও coordinator সবার ভোটের অপেক্ষা করে, তাই 2PC-এর latency সবচেয়ে ধীর participant-এর latency — একটি fan-out, যেখানে কারও p99 সবার সাধারণ সময় হয়ে দাঁড়ায় (পর্ব ০৪)। Availability-তে: commit-এ coordinator আর সব participant-কে একসাথে সচল থাকতে হয়, অর্থাৎ এরা series-এ (পর্ব ০৫)। প্রত্যেকে ৯৯.৯% হলে চারজনের মিলিত availability ০.৯৯৯^৪ ≈ ৯৯.৬০% — বছরে প্রায় ৩৫ ঘণ্টা commit বন্ধ, একটি যন্ত্রে যেখানে প্রায় ৮.৮ ঘণ্টা।

প্রচলিত optimization

• Presumed abort: log-এ কোনো লেনদেনের খবর না থাকলে ধরে নেওয়া হয় ABORT, তাই abort-এ force বা ACK লাগে না — IBM-এর R* প্রকল্পের ১৯৮৬ সালের গবেষণাপত্রে (Mohan, Lindsay ও Obermarck) বর্ণিত।
• Read-only আর one-phase: শুধু পড়েছে এমন participant ধাপ ২ থেকে বাদ পড়ে; লেখার participant একজন হলে 2PC-ই লাগে না।
• Group commit: অনেক লেনদেনের log একটি fsync-এ — f-এর গড় খরচ কমে, কিন্তু round trip আর lock-এর সময় কমে না।

৫ · Blocking এড়ানোর চেষ্টা — three-phase commit আর consensus-ভিত্তিক commit

Skeen-এর পর্যবেক্ষণ: 2PC-তে একটি participant এমন অবস্থায় থাকতে পারে (prepared), যেখান থেকে commit আর abort দুটোই তখনও সম্ভব — তাই সে আটকায়। Three-phase commit (3PC) মাঝে একটি ধাপ বসায়:

1. CanCommit? → ভোট, 2PC-এর prepare-এর মতো।
2. PreCommit: সব YES হলে coordinator সবাইকে জানায় “সবাই রাজি, সিদ্ধান্ত commit হবে”; participant ACK দেয়।
3. DoCommit: তারপর আসল commit.

এখন অবস্থা দেখেই বোঝা যায় কী করতে হবে: কেউ PreCommit পেয়ে থাকলে সবাই YES দিয়েছিল, তাই commit নিরাপদ; কেউই না পেলে কেউ commit করেনি, তাই abort নিরাপদ। Coordinator মরলে বেঁচে থাকা participant-রা নতুন coordinator বেছে কাজ শেষ করতে পারে।

এর পেছনে একটি গভীর ফল আছে। ১৯৮৫ সালে Fischer, Lynch ও Paterson প্রমাণ করেন (FLP impossibility): বার্তার সময়ের সীমা নেই এমন (asynchronous) ব্যবস্থায় একটি process-ও crash করতে পারলে কোনো deterministic প্রোটোকল সবসময় ঐকমত্যের নিশ্চয়তা দিতে পারে না; non-blocking atomic commit এই ঐকমত্যেরই আত্মীয়। বাস্তবের উত্তর: নিরাপত্তা সবসময়, আর অগ্রগতি তখন, যখন বেশিরভাগ যন্ত্র সচল আর যোগাযোগে।

Coordinator-কে একা না রাখা — Paxos আর Raft দিয়ে

2PC-এর আসল সমস্যা, সিদ্ধান্তটি একটি যন্ত্রের ডিস্কে। সমাধান: সিদ্ধান্ত আর PREPARED অবস্থা কয়েকটি replica-য় consensus দিয়ে লেখা — Paxos বা Raft-এ, যেখানে বেশিরভাগ replica লিখলে তবেই record টেকসই। Coordinator-এর যন্ত্র মরলে অন্য replica leader হয়ে log থেকে সিদ্ধান্ত পড়ে কাজ শেষ করে (Raft পর্ব ৪২-এ)।

• Paxos Commit: Jim Gray আর Leslie Lamport-এর “Consensus on Transaction Commit” (ACM TODS, ২০০৬) — Paxos Commit; ২F + ১টি acceptor F-টি ব্যর্থতা সহ্য করে, আর F = ০ হলে এটি আসলে 2PC.
• Spanner-এর ধাঁচ: Google-এর Spanner-এর ২০১২ সালের (OSDI) গবেষণাপত্র অনুযায়ী প্রতিটি participant একটি Paxos দল, একটি দলের leader coordinator, আর PREPARE ও COMMIT record Paxos-এ replicated — আটকায় কেবল কোনো দলের majority হারালে।
• দাম: প্রতিটি forced write এখন একটি consensus round — কয়েকটি replica-য় fsync আর অন্তত একটি round trip, প্রায়ই আলাদা zone-এ। Latency বাড়ে, blocking-এর ঝুঁকি কমে।

৬ · Saga — local transaction-এর শিকল আর compensation

১৯৮৭ সালে Hector Garcia-Molina আর Kenneth Salem SIGMOD-এ “Sagas” গবেষণাপত্রে দীর্ঘ লেনদেনের (long-lived transaction) ঘণ্টার পর ঘণ্টা lock-এর সমাধান দেন: লেনদেনটিকে ছোট local transaction T1 … Tn-এ ভাগ, প্রতিটি সঙ্গে সঙ্গে commit, আর প্রতিটির একটি compensating transaction C1 …, যা প্রভাবটি অর্থের দিক থেকে উল্টে দেয়। নিশ্চয়তা: হয় T1 … Tn সব, নয়তো T1 … Tj আর তারপর উল্টো ক্রমে Cj … C1. এক ডেটাবেসের জন্য লেখা এই ধারণাই আজ কয়েক সেবা জুড়ে কাজের প্রধান কৌশল — saga.

দুই দিকে মেরামত — backward আর forward recovery

• Backward recovery: আগের সফল ধাপগুলোর compensation, উল্টো ক্রমে — saga বাতিল।
• Forward recovery: ব্যর্থ ধাপটি আবার চেষ্টা করে এগোনো — যখন ব্যর্থতা ক্ষণিকের আর ধাপটি শেষ পর্যন্ত সফল হবেই; মূল গবেষণাপত্রেও save-point থেকে এগোনোর কথা আছে।

নিয়ম: ব্যবসায়িক “না” (ট্রিপ বাতিল, ব্যালান্স কম) হলে backward; ক্ষণিকের ত্রুটিতে একই idempotency key-সহ retry, exponential backoff ও jitter দিয়ে (পর্ব ৪৮); তারপরও না হলে backward, বা মানুষের হাতে।

Compensation নকশা — “undo” নয়, একটি নতুন কাজ

• অর্থের দিক থেকে উল্টানো: টাকা ফেরত মানে সারিকে আগের মানে ফেরানো নয়, ledger-এ একটি নতুন refund entry — মুদি দোকানের খাতায় যেমন ভুল কেটে না মুছে নিচে লেখা হয় “ফেরত ৮৫০”; ইতিহাস থাকে, হিসাব মেলে।
• শেষ পর্যন্ত সফল হতেই হবে, আর idempotent: নইলে saga আধাআধি পড়ে থাকে; তাই retry চলে idempotency key-সহ (যেমন s42-ChargePayment), আর বারবার ব্যর্থ হলে alert ও মানুষের হাতে।
• শর্তসাপেক্ষ: “A3 free” নয়, “A3 এখনো s42-এর HELD হলে তবেই free” — নইলে অন্য কাজের বদল মুছে যায় (অংশ ৭-এর লাইভ SQL).
• সব কাজ উল্টানো যায় না: পাঠানো SMS বা ছাপা টিকিটের “compensation” শুধু আরেকটি সংশোধনী কাজ — এদের saga-র শেষে রাখুন।

Pivot — যেখানে ফেরার পথ বন্ধ

Chris Richardson-এর Microservices Patterns (২০১৮) বইয়ে জনপ্রিয় হওয়া একটি শ্রেণিবিভাগে ধাপ তিন রকম: compensatable, একটি pivot transaction (সফল হলে saga শেষ পর্যন্ত যাবেই, ব্যর্থ হলে আগেরগুলো উল্টাতে হয়), আর pivot-এর পরের retriable ধাপ। বাস-টিকিটে: BookSeat (hold, উল্টানো প্রায় বিনামূল্যে) → ChargePayment (refund-এ উল্টানো যায়, খরচসহ) → IssueTicket (অপারেটর টিকিট দিলে আর ফেরা নেই — pivot) → SendSMS (retriable).

ক্রমের নিয়ম: যে ধাপ ব্যর্থ হওয়ার সম্ভাবনা বেশি আর উল্টানো সস্তা, সেটি আগে; উল্টানো যায় না এমন কাজ pivot-এর পরে। তাই সিট আগে hold, তারপর টাকা — hold ছাড়তে কিছু লাগে না, refund-এ সময় আর মাশুল লাগে।

এবার একটি saga ধাপে ধাপে। Orchestrator (Booking service) তিনটি ধাপ চালায়; তৃতীয় ধাপে অপারেটর জানায় ট্রিপটি বাতিল — ব্যবসায়িক “না”, তাই backward recovery. সাথে, refund-এর প্রথম উত্তরটি হারায়।

একই ঘটনা simulator-এ। প্রতিটি সেবা একটি ছোট in-memory অংশ; FAIL_AT বলে কোন ধাপ স্থায়ীভাবে ব্যর্থ হবে, আর refund-এর প্রথম উত্তরটি সবসময় হারায়:

// Saga orchestrator: BookSeat -> ChargePayment -> IssueTicket. Deterministic, in-memory services.
const FAIL_AT = 3;                     // which forward step fails for good (1..3); 0 = none fails
const db = { seat: "free", wallet: 5000, ticket: "none", refundKeys: new Set() }; let refundCalls = 0;
const log = [], ev = (s) => log.push(String(log.length + 1).padStart(2, "0") + " " + s);
function refund(key) {                 // payment service: refund is idempotent on its key
  refundCalls++;
  if (db.refundKeys.has(key)) return "already refunded, no-op";
  db.refundKeys.add(key); db.wallet += 850;
  if (refundCalls === 1) throw new Error("timeout (refund applied, reply lost)");
  return "refunded 850";
}
const steps = [
  { name: "BookSeat", why: "seat A3 already sold", run: () => { db.seat = "A3 HELD (pending)"; },
    undo: () => { db.seat = "free"; return "seat released"; } },
  { name: "ChargePayment", why: "balance too low", run: () => { db.wallet -= 850; }, undo: refund },
  { name: "IssueTicket", why: "operator rejected: trip cancelled",          // pivot: no undo
    run: () => { db.seat = "A3 SOLD"; db.ticket = "T-501"; } },
];
const done = []; ev("SAGA s42 STARTED");
for (const [i, s] of steps.entries()) {
  if (i + 1 === FAIL_AT) { ev(s.name + " FAILED: " + s.why); break; }
  s.run(); done.push(s); ev(s.name + " OK");
}
if (done.length < steps.length) {
  ev("COMPENSATING in reverse order");
  for (const s of done.reverse())
    for (let n = 1; ; n++) {           // retry with the SAME key until it succeeds
      try { ev("undo " + s.name + " try " + n + ": " + s.undo("s42-" + s.name)); break; }
      catch (e) { ev("undo " + s.name + " try " + n + ": " + e.message + " -> retry"); }
    }
  ev("SAGA s42 COMPENSATED");
} else ev("SAGA s42 COMPLETED");
log.forEach((l) => console.log(l));
console.log("final: seat=" + db.seat + ", wallet=" + db.wallet + ", ticket=" + db.ticket +
  ", refund calls=" + refundCalls + ", refunds applied=" + db.refundKeys.size);

01 SAGA s42 STARTED
02 BookSeat OK
03 ChargePayment OK
04 IssueTicket FAILED: operator rejected: trip cancelled
05 COMPENSATING in reverse order
06 undo ChargePayment try 1: timeout (refund applied, reply lost) -> retry
07 undo ChargePayment try 2: already refunded, no-op
08 undo BookSeat try 1: seat released
09 SAGA s42 COMPENSATED
final: seat=free, wallet=5000, ticket=none, refund calls=2, refunds applied=1

Orchestration বনাম choreography

উপরের saga-য় একটি কেন্দ্রীয় সেবা সব ধাপ চালায় — orchestration. বিকল্প choreography: কোনো কেন্দ্র নেই; SeatHeld শুনে পেমেন্ট টাকা কাটে, PaymentCharged শুনে টিকিট সার্ভিস কাজ ধরে, TicketRejected শুনে পেমেন্ট refund করে, আর PaymentRefunded শুনে সিট সার্ভিস hold ছাড়ে।

বিস্তারিত তুলনা পর্ব ৩২-এ (pub/sub আর event-driven architecture). Orchestrator নিজেও crash করতে পারে, তাই তার অবস্থা ডেটাবেসে টেকসই রাখতে হয়; Temporal-এর মতো open-source workflow engine ধাপ, retry, timer আর অবস্থা নিজেই টেকসই রাখে (পর্ব ৩৭)।

৭ · Saga-য় isolation নেই — anomaly আর প্রতিকার

Saga দেয় ACID-এর A (শেষে সব, নয়তো compensation), C (প্রতিটি সেবার নিয়ম) আর D (প্রতিটি local commit টেকসই) — কিন্তু I নয়: প্রতিটি T নিজে commit করে, তাই মাঝের অবস্থা সবার কাছে দৃশ্যমান। পর্ব ২৪-এর anomaly-গুলো ফিরে আসে, এবার lock-এর পাহারা ছাড়াই:

প্রতিকারের পুরো তালিকা

• Semantic lock: compensatable ধাপ একটি অপেক্ষমাণ পতাকা বসায় (সিট HELD, অর্ডার PENDING); pivot বা compensation সেটি সরায়, আর অন্যরা দেখে অপেক্ষা করে বা গ্রাহককে “অপেক্ষমাণ” দেখায়। এর একটি মেয়াদ (TTL) রাখুন — বাস কাউন্টারে যেমন ১০ মিনিট পরে hold ছেড়ে দেওয়া হয় — যাতে মরে যাওয়া saga চিরকাল সিট আটকে না রাখে।
• Commutative update: “balance = ৪,১৫০” নয়, বরং “−৮৫০” আর “+৮৫০” — ক্রম যা-ই হোক, ফল এক।
• Pessimistic view: অন্যরা যে ডেটা পড়ে সিদ্ধান্ত নেয়, তা retriable ধাপে বদলানো।
• Reread value: লেখার আগে version কলাম দিয়ে আবার যাচাই, পর্ব ০৮-এর ETag-এর মতো।
• Version file: কাজের হিসাব রাখা, যাতে উল্টো ক্রমে আসা কাজ (বাতিল আগে, তৈরি পরে) চেনা যায়।
• By value: ঝুঁকি বুঝে কৌশল — বড় অঙ্কের কাজে কড়া পদ্ধতি, সাধারণ কাজে saga.

মূল কথা (Richardson-এর বইয়ে বিস্তারিত): অপেক্ষমাণ অবস্থাকে ডেটায় স্পষ্ট করুন, আর প্রতিটি লেখাকে শর্তসাপেক্ষ বা ক্রম-নিরপেক্ষ রাখুন। নিচের লাইভ SQL-এ উপরের lost update-টি, দুই রকম compensation দিয়ে; নমুনা ডেটাবেসে ট্রিপ ৭-এর A3 আর A4 free, B1 SOLD.

-- Saga s42, step 1: hold seat A3 (a semantic lock: HELD + who holds it).
UPDATE seats SET state = 'HELD', hold_by = 's42', version = version + 1
WHERE trip = 7 AND seat = 'A3' AND state = 'free';
-- Meanwhile the operator cancels trip 7: every seat becomes CANCELLED.
UPDATE seats SET state = 'CANCELLED', hold_by = NULL, version = version + 1
WHERE trip = 7;
-- s42 fails later and compensates. The guarded compensation touches A3
-- only if it is STILL held by s42:
UPDATE seats SET state = 'free', hold_by = NULL, version = version + 1
WHERE trip = 7 AND seat = 'A3' AND state = 'HELD' AND hold_by = 's42';
SELECT seat, state, hold_by, version FROM seats ORDER BY seat;
-- A naive compensation ("make A3 free") resurrects a seat on a cancelled trip:
UPDATE seats SET state = 'free', hold_by = NULL WHERE trip = 7 AND seat = 'A3';
SELECT seat, state FROM seats WHERE trip = 7 ORDER BY seat;

৮ · Dual write-এর ফাঁদ আর transactional outbox

Orchestration হোক বা choreography, প্রতিটি সেবাকে দুটি কাজ করতে হয়: নিজের ডেটাবেসে লেখা, আর অন্যদের জানাতে message broker-এ (Kafka বা RabbitMQ-র মতো; পর্ব ৩১, ৩৩) বার্তা পাঠানো। কোড প্রায়ই এমন দেখায়:

await db.transaction(async (tx) => {
  await tx.insert("orders", order);              // 1. commit the order
});
await broker.publish("OrderPlaced", event);       // 2. then tell the others
// The process can die between 1 and 2, or publish can time out.

একে বলে dual write — দুটি আলাদা ব্যবস্থায় দুটি লেখা, মাঝে কোনো যৌথ transaction নেই। লাইন ১ আর ২-এর মাঝে process মরতে পারে, broker বন্ধ থাকতে পারে, publish-এ timeout হলে বার্তা গেছে কি না অজানা। ক্রম উল্টালে উল্টো বিপদ: event গেল, অর্ডার commit হলো না। try/catch সারায় না — catch-এর আগেই process মরতে পারে। আর publish-এর timeout-এ “গেল কি না জানি না” — এই অনিশ্চয়তা অনেকটা দুই সেনাপতির সমস্যার মতো।

ক্ষতি কতটা? নিচের simulator-এ ১০,০০০টি অর্ডার, প্রতিটির জন্য তিন পদ্ধতিতে একই seeded দুর্ঘটনা: ১% ক্ষেত্রে ডেটাবেসের লেখা ব্যর্থ, ২% ক্ষেত্রে broker সাময়িক বন্ধ, ০.৫% ক্ষেত্রে দুই কাজের মাঝে crash — সবই ধরে নেওয়া হার:

// Dual write vs transactional outbox: 10,000 orders, the SAME seeded faults for every approach.
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 = 10000, DB_FAIL = 0.01, BROKER_FAIL = 0.02, CRASH = 0.005;   // assumed fault rates
function simulate(mode) {
  const r = mulberry32(1), orders = new Set(), events = []; let retries = 0;
  for (let id = 1; id <= N; id++) {
    const dbFails = r() < DB_FAIL, brokerFails = r() < BROKER_FAIL, crash = r() < CRASH;
    if (mode === "db-then-publish") {          // commit the order, then publish
      if (dbFails) continue;
      orders.add(id);
      if (!crash && !brokerFails) events.push(id);   // crash in between or broker down: lost
    } else if (mode === "publish-then-db") {   // publish first, then commit
      if (brokerFails) continue;
      events.push(id);
      if (!crash && !dbFails) orders.add(id);        // event is out, order is not: phantom
    } else {                                   // outbox: order + event row in ONE transaction
      if (dbFails) continue;                   // both rows rolled back together
      orders.add(id);
      if (brokerFails) retries++;              // relay keeps the row and tries again later
      events.push(id);
      if (crash) events.push(id);              // relay died before marking it sent: sent twice
    }
  }
  const uniq = new Set(events);
  const lost = [...orders].filter((id) => !uniq.has(id)).length;
  const phantom = [...uniq].filter((id) => !orders.has(id)).length;
  console.log(mode.padEnd(16) + String(orders.size).padStart(7) + String(events.length).padStart(8) +
    String(lost).padStart(6) + String(phantom).padStart(9) + String(events.length - uniq.size).padStart(6) +
    (mode === "outbox" ? "   relay retries=" + retries + ", deduped consumer applies " + uniq.size : ""));
}
console.log("approach         orders  events  lost  phantom  dups");
["db-then-publish", "publish-then-db", "outbox"].forEach(simulate);

approach         orders  events  lost  phantom  dups
db-then-publish    9895    9653   242        0     0
publish-then-db    9653    9802     0      149     0
outbox             9895    9943     0        0    48   relay retries=194, deduped consumer applies 9895

Outbox — event-টিও ডেটাবেসের একটি সারি

Transactional outbox-এর কৌশল সরল: event সরাসরি broker-এ না পাঠিয়ে একই ডেটাবেসের outbox টেবিলে লিখুন — ব্যবসায়িক সারির সাথে একই local transaction-এ। আলাদা একটি relay process না-পাঠানো সারি পড়ে broker-এ পাঠায়, তারপর “পাঠানো হয়েছে” চিহ্ন দেয় বা সারিটি মোছে। ফল:

• সব, নয়তো কিছুই না: অর্ডার commit হলে event-ও আছে, না হলে কোনোটিই নেই।
• হারায় না: relay বা broker বন্ধ থাকলে সারিটি অপেক্ষা করে, পরে যায়।
• কিন্তু দুবার যেতে পারে: পাঠানো আর চিহ্নের মাঝে relay মরলে — তাই outbox দেয় at-least-once delivery, আর প্রতিটি consumer-কে হতে হয় idempotent consumer: event_id-এর একটি inbox টেবিল, effect-এর সাথে একই local transaction-এ (পর্ব ৩৪)।

Saga, প্রতিটি সেবার নিজের ডেটাবেস, outbox আর broker — পুরো ছবি একসাথে:

এবার relay-র পথ ধাপে ধাপে — একটি crash-সহ, যাতে duplicate কোথা থেকে আসে আর কীভাবে থামে, দেখা যায়:

একই ঘটনা লাইভ SQL-এ। নমুনা ডেটাবেসে orders; outbox (event_id অনন্য, sent_at NULL মানে না-পাঠানো, আর না-পাঠানো সারির একটি partial index); message broker-এর ভূমিকায় broker; আর consumer-এর inbox, যেখানে event_id primary key. ROLLBACK crash-এর ভূমিকায়; relay-র crash মানে চিহ্ন দেওয়ার UPDATE-টি বাদ:

-- 1) Place order 1001: the order row and its event row commit TOGETHER.
BEGIN;
INSERT INTO orders VALUES (1001, 'A3', 850, 'PENDING');
INSERT INTO outbox (event_id, type, payload) VALUES ('ev-1001', 'OrderPlaced', '{"order":1001,"seat":"A3"}');
COMMIT;
-- 2) Order 1002 crashes before COMMIT (ROLLBACK plays the crash): neither row survives.
BEGIN;
INSERT INTO orders VALUES (1002, 'A4', 850, 'PENDING');
INSERT INTO outbox (event_id, type, payload) VALUES ('ev-1002', 'OrderPlaced', '{"order":1002,"seat":"A4"}');
ROLLBACK;
SELECT (SELECT count(*) FROM orders) AS orders, (SELECT count(*) FROM outbox) AS outbox_rows;
-- 3) Relay, run 1: read unsent rows, publish them ... and crash before marking them sent.
SELECT id, event_id FROM outbox WHERE sent_at IS NULL ORDER BY id LIMIT 100;
INSERT INTO broker (event_id) SELECT event_id FROM outbox WHERE sent_at IS NULL ORDER BY id;
-- 4) Relay, run 2 (after restart): the row is still unsent, so it goes out AGAIN, then is marked.
INSERT INTO broker (event_id) SELECT event_id FROM outbox WHERE sent_at IS NULL ORDER BY id;
UPDATE outbox SET sent_at = '2026-10-28 10:00:05' WHERE sent_at IS NULL;
-- 5) Consumer: remember each event_id once; a second copy changes 0 rows, so no second SMS.
INSERT OR IGNORE INTO inbox SELECT event_id FROM broker WHERE seq = 1;
INSERT OR IGNORE INTO inbox SELECT event_id FROM broker WHERE seq = 2;
SELECT b.seq, b.event_id, o.sent_at, (SELECT count(*) FROM inbox) AS applied
FROM broker b JOIN outbox o USING (event_id) ORDER BY b.seq;

Relay বাস্তবে — polling, ক্রম আর CDC

• Polling relay: কয়েকশো মিলিসেকেন্ড পরপর WHERE sent_at IS NULL; এই শর্তে একটি partial index (পর্ব ২১), আর পাঠানো সারি নিয়মিত মোছা। কয়েকটি worker চালাতে PostgreSQL আর MySQL 8-এ FOR UPDATE SKIP LOCKED প্রচলিত (সংস্করণভেদে আলাদা)।
• ক্রম: একই অর্ডারের event-এর ক্রম চাইলে order id-কে message key করুন, যাতে একই partition-এ যায় (পর্ব ৩৩); consumer sequence number দিয়ে যাচাই করতে পারে।
• Change data capture (CDC): polling-এর বদলে ডেটাবেসের transaction log (MySQL-এর binlog, PostgreSQL-এর logical decoding) পড়ে event বানানো; Debezium-এর মতো open-source টুল outbox-এর নতুন সারিগুলো log থেকেই তুলে পাঠাতে পারে। লাভ: polling নেই, commit-এর ক্রম রক্ষা; দাম: আরেকটি চালু ব্যবস্থা আর ডেটাবেস-নির্দিষ্ট সেটআপ।
• আরেকটি পথ: event-ই যদি আসল ডেটা হয় — event sourcing — তাহলে লেখা একটিই, dual write থাকে না (পর্ব ৩৫)।

৯ · কোনটি কখন — বাছাইয়ের ছক আর idempotency-র সুতো

সব কৌশল এক ছকে। প্রশ্ন সবসময় একই: রক্ষা করার নিয়মটি (invariant) কয়টি ডেটাবেস জুড়ে, কতক্ষণের, আর কার নিয়ন্ত্রণে?

পুরো পথে idempotency — প্রতিটি কড়ায় একটি key

Saga আর outbox দুটোই retry আর duplicate-এর ওপর দাঁড়িয়ে, তাই শিকলের প্রতিটি কড়ায় একটি key:

1. App → API: Idempotency-Key header (পর্ব ০৮)।
2. Orchestrator → সেবা: saga id আর ধাপ, যেমন s42-ChargePayment.
3. Compensation: নিজস্ব key — simulator-এর refund-এর মতো।
4. Relay → broker: প্রতিটি event-এর event_id, সাধারণত UUID.
5. Consumer: inbox-এ event_id, effect-এর সাথে একই local transaction-এ।
6. পেমেন্ট → বাইরের gateway: একই বা তা থেকে বানানো key, যাতে আমাদের retry-তে দ্বিতীয় চার্জ না হয়।

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

“Microservice-এ অর্ডার, পেমেন্ট আর inventory কীভাবে consistent রাখব?” — AI প্রায়ই বলে, “Saga ব্যবহার করুন, Kafka দিয়ে event পাঠান।” ভুল নয়, কিন্তু আসল কাজ — কোন ধাপের compensation কী, কোনটি pivot, কোথায় duplicate আসবে — বাদ পড়ে। চেনা ভুলগুলো:

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

• আগে দেখেছি, ডেটাগুলো এক ডেটাবেসে বা এক shard-এ আনা যায় কি না
• প্রতিটি saga ধাপের compensation, pivot আর retriable ধাপ চিহ্নিত; compensation শর্তসাপেক্ষ আর idempotent
• কোথাও dual write নেই; প্রতিটি event outbox বা CDC দিয়ে যায়
• প্রতিটি consumer event_id দিয়ে duplicate বাদ দেয়; প্রতিটি retry একই key ব্যবহার করে
• 2PC থাকলে latency, lock আর availability নিজে হিসাব করেছি
• Coordinator, orchestrator আর relay-র crash simulator-এ চালিয়েছি; পণ্যের দাবি ডকুমেন্টেশনে মিলিয়েছি