Saga pattern: microservice জুড়ে transaction

Order দিতে গেলে payment, stock ও shipping আলাদা service-এ যায়। Saga distributed transaction ছাড়াই এদের সামঞ্জস্য রাখে।

ফেরত তীরসহ ধাপের একটি শিকল

এক database-এর monolith-এ order দেওয়া একটি transaction: stock রাখো, payment নাও, shipment বানাও, কিছু ব্যর্থ হলে সব rollback। Microservice-এ প্রতিটি service-এর নিজের database, তাই কোনো একক transaction সবকিছু ঢাকে না। Saga হলো local transaction-এর ক্রম, যেখানে পরের ধাপ ব্যর্থ হলে প্রতিটি ধাপ ফেরানোর জন্য compensating action থাকে।

উদাহরণ: order দেওয়া

  1. Order service: order PENDING হিসেবে তৈরি।
  2. Inventory service: পণ্য reserve।
  3. Payment service: গ্রাহকের কাছ থেকে টাকা নেওয়া।
  4. Shipping service: ডেলিভারির সময়সূচি।
  5. Order service: CONFIRMED চিহ্নিত।

ধাপ ৩-এ payment ব্যর্থ হলে saga উল্টো ক্রমে compensation চালায়: reserve করা পণ্য ছেড়ে দেওয়া, তারপর order বাতিল।

Compensation মানে rollback নয়

Compensating action একটি নতুন business কাজ, যেমন "payment ফেরত দাও" বা "shipment বাতিল করো"। এটি দুনিয়াকে হুবহু আগের অবস্থায় আনতে নাও পারে (ইমেইল হয়তো চলে গেছে), তাই ধাপ এমনভাবে বানান যাতে compensation ব্যবসার দিক থেকে অর্থপূর্ণ হয়।

সমন্বয়ের দুই উপায়

Choreography। প্রতিটি service event শোনে ও প্রতিক্রিয়া দেখায়, নিজের event publish করে। কেন্দ্রীয় নিয়ন্ত্রক নেই।

  • কয়েক ধাপে সহজ, শিথিলভাবে যুক্ত।
  • বড় হলে পুরো প্রবাহ দেখা ও debug করা কঠিন।

Orchestration। কেন্দ্রীয় orchestrator প্রতিটি service-কে পরের কাজ বলে এবং ব্যর্থতা সামলায়।

  • পরিষ্কার প্রবাহ, নজর রাখা ও বদল সহজ।
  • Orchestrator আরেকটি উপাদান যা বানাতে ও নির্ভরযোগ্য রাখতে হয়।

যা অবশ্যই সামলাতে হবে

  • Idempotency: message বারবার আসতে পারে, তাই প্রতিটি ধাপ ও compensation দুবার চালালেও নিরাপদ হতে হবে।
  • Compensation নিজেই ব্যর্থ হলে: সফল না হওয়া পর্যন্ত retry করুন, না পারলে মানুষকে alert দিন।
  • অর্ধেক হওয়া অবস্থা: অন্য user মুহূর্তের জন্য pending order দেখতে পারে। অবস্থা সৎভাবে দেখান।
  • Saga-র অবস্থা সংরক্ষণ করুন যাতে crash হলেও প্রক্রিয়া টিকে থাকে।
  • যে ধাপ কখনো উত্তর দেয় না তার জন্য timeout।

কখন এড়াবেন

সম্পর্কিত data এক service ও এক database-এ রাখতে পারলে তাই করুন। Saga হলো service জুড়ে data ভাগ করার দাম।

মূল কথা: service জুড়ে কাজের প্রবাহে saga ব্যবহার করুন। প্রবাহ বড় হলে orchestration বেছে নিন, আর প্রতিটি ধাপ ও তার compensation idempotent রাখুন।


System Design সিরিজ, পর্ব ২ (building block): 14 নম্বর (মোট 14)। আগের লেখা: Event sourcing: শুধু বর্তমান অবস্থা নয়, event রাখুন.

আরও পড়ুন

Recursion ও backtracking সহজ উদাহরণে

Recursion সমস্যার ছোট কপি সমাধান করে সমাধান করে। অনেক interview সমস্যায় ব্যবহৃত চিন্তার ধাপ ও backtracking টেমপ্লেট শিখুন।

Interview ও DSA•৩ মিনিটে পড়া