Part 2 · ডেটাবেস 📖 ১৪ মিনিট পড়া 📝 ২০টি কুইজ

Distributed Transactions

একাধিক service বা DB মিলিয়ে একটি logical operation।

📝 কুইজে যান

একটি e-commerce-এ "অর্ডার করুন" বাটনে চাপ দিলে: Order service order create করে, Payment service কার্ড থেকে কাটে, Inventory service stock কমায়, Shipping service shipment book করে। যদি এর মধ্যে যেকোনো একটি fail হয় — আগেরগুলো undo করতে হবে। কিন্তু এগুলো আলাদা service ও DB। এটাই Distributed Transaction।

Distributed Transaction কী?

Distributed Transaction = এমন transaction যা একাধিক resource (DB, service, system)-এ span করে। সব সফল হবে — অথবা কেউই না। Microservice আর্কিটেকচারে অনিবার্য সমস্যা।

কেন কঠিন?

  • No global lock: এক DB-এর transaction অন্য DB-কে control করতে পারে না।
  • Network failure: Service down/timeout — partial failure সাধারণ।
  • Independent failure: প্রতিটি service আলাদাভাবে fail হতে পারে।
  • Long duration: Multi-step transaction-এ সময় বেশি।
  • CAP theorem: Distributed-এ trade-off অনিবার্য।

Two-Phase Commit (2PC)

Classic distributed transaction protocol — coordinator + participant।

Phase 1: Prepare

  1. Coordinator সব participant-কে "prepare" পাঠায়।
  2. Each participant: কাজ করতে পারলে "yes" বলে এবং lock করে রাখে।
  3. না পারলে "no" বলে।

Phase 2: Commit / Abort

  1. সবাই "yes" বললে — coordinator "commit" পাঠায়। সবাই commit।
  2. কেউ "no" বললে — "abort"। সবাই rollback।
Coordinator → Participants PHASE 1: "Can you commit?" ← "Yes / No" PHASE 2: "Commit!" বা "Abort!"

সমস্যা

  • Blocking: Phase 1-এর পর coordinator fail করলে — participants infinite wait।
  • Slow: Two round trip + lock।
  • Single point of failure: Coordinator।
  • Reduced availability: Lock দীর্ঘ সময়।

3PC (Three-Phase Commit)

2PC-এর blocking সমস্যা কমাতে — extra "pre-commit" phase। Practical-এ rare।

Saga Pattern

Distributed transaction-এর modern বিকল্প। বড় transaction-কে ছোট local transaction-এ ভেঙে — প্রতিটির compensating action সহ।

উদাহরণ — Order workflow

  1. Order service: order create। Compensation: cancel order।
  2. Payment service: payment। Compensation: refund।
  3. Inventory: stock কমান। Compensation: stock ফেরত।
  4. Shipping: book। Compensation: cancel shipping।

মাঝে fail হলে — সব previously-completed step-এর compensation চালানো।

Saga-র দুই pattern

Choreography

প্রতিটি service event publish করে, পরের service listen করে। কোনো central coordinator নেই।

  • সুবিধা: Loose coupling।
  • অসুবিধা: Workflow visualize কঠিন; cyclic dependency risk।

Orchestration

একটি orchestrator service flow control করে।

  • সুবিধা: Centralized logic, easier debug।
  • অসুবিধা: Orchestrator nije complex।

TCC (Try-Confirm-Cancel)

প্রতিটি service-এ তিনটি step:

  • Try: Resource reserve (যেমন stock 1 hold)। Tentative।
  • Confirm: সব try সফল হলে — finalize।
  • Cancel: কেউ fail হলে — সব try রিলিজ।

উদাহরণ

Banking transfer:

  • Try: A-র account-এ ১০০০ "frozen" mark।
  • Try: B-র account-এ ১০০০ "incoming" mark।
  • Confirm (both OK): actual debit/credit।
  • Cancel: marks remove।

2PC vs Saga vs TCC

2PC

  • ACID guarantee
  • Strong consistency
  • Blocking, slow
  • Single coordinator failure risk
  • Modern microservice-এ rare

Saga

  • Eventually consistent
  • No blocking
  • Compensating action design
  • Long-running OK
  • Microservice-এ standard

TCC

  • Reservation-based
  • Fast (no long lock)
  • Each service-এ Try/Confirm/Cancel
  • Banking-এ ব্যবহৃত
  • Complex implementation

Outbox Pattern

Saga-তে event publish-এ atomicity সমস্যা — DB write ও event publish একসাথে fail হতে পারে। সমাধান: একই transaction-এ event-কে "outbox table"-এ লেখা। Background worker সেটা পরে publish করে।

BEGIN; INSERT INTO orders ...; INSERT INTO outbox (event) VALUES ('OrderCreated'); COMMIT; -- Background worker outbox থেকে event publish।

বাস্তব উদাহরণ

  • Uber: Saga pattern — trip lifecycle (request → match → start → end → payment)।
  • Netflix: Choreography saga across microservice।
  • Amazon checkout: Saga + outbox pattern।
  • Banking core: TCC বা strict 2PC।

সাধারণ ভুল ধারণা

  1. "Microservice-এ ACID transaction পাবো": না — distributed transaction completely ACID দেয় না।
  2. "2PC widely used": Modern microservice-এ rarely।
  3. "Saga = simple": Compensating action design কঠিন।
  4. "Eventually consistent OK সবসময়": Banking-এ acceptable না।

Best Practices

  • Possible হলে — distributed transaction এড়িয়ে চলুন। Bounded context-এ DB এক রাখুন।
  • Saga choose করুন microservice-এ।
  • Idempotent compensating action — multiple invoke সহিনয়।
  • Outbox pattern atomicity-র জন্য।
  • Monitoring crucial — long saga track।
  • State machine দিয়ে saga model।

📌 চ্যাপ্টার সারমর্ম

  • Distributed transaction = একাধিক service-এ atomic operation।
  • 2PC: classic, ACID, কিন্তু blocking।
  • Saga: compensating action দিয়ে — modern microservice-এ standard।
  • TCC: Try-Confirm-Cancel — banking-এ ব্যবহৃত।
  • Outbox pattern atomic event publish-এর জন্য।