SAGA প্যাটার্ন — ডিস্ট্রিবিউটেড ট্রানজেকশন ম্যানেজমেন্ট

১ · কেন 2PC মাইক্রোসার্ভিসে ভালো মানায় না

L18-এ আমরা দেখেছি Two-Phase Commit (2PC) কীভাবে একটি কোঅর্ডিনেটরের মাধ্যমে সব অংশগ্রহণকারীকে একসাথে কমিট বা অ্যাবোর্ট করায়। কিন্তু এর একটি বড় দুর্বলতা আছে — এটি blocking: Phase 1-এ ভোট দেওয়ার পর একটি অংশগ্রহণকারী তার রিসোর্স লক করে রাখে এবং কোঅর্ডিনেটরের চূড়ান্ত সিদ্ধান্তের জন্য অপেক্ষা করে। কোঅর্ডিনেটর যদি সেই মুহূর্তে ক্র্যাশ করে, লকগুলো অনির্দিষ্টকালের জন্য আটকে থাকতে পারে। মাইক্রোসার্ভিস আর্কিটেকচারে (L25) প্রতিটি সার্ভিসের নিজস্ব ডেটাবেস থাকে এবং সার্ভিসগুলো স্বাধীনভাবে স্কেল/ডিপ্লয় হতে চায় — এমন একটি টাইট-কাপলড, ব্লকিং মেকানিজম এই লক্ষ্যের সরাসরি বিপরীত।

২ · SAGA প্যাটার্ন — Compensating Transaction দিয়ে সমাধান

SAGASAGA Patternএকটি ডিস্ট্রিবিউটেড ট্রানজেকশনকে একাধিক স্থানীয় (local) ট্রানজেকশনের ধারাবাহিকতায় ভাঙা হয়, প্রতিটির একটি নির্দিষ্ট compensating transaction থাকে যা প্রয়োজনে সেই ধাপের প্রভাব বাতিল করে দেয়। প্রতিটি ধাপকে একটি স্বাধীন লোকাল ট্রানজেকশন হিসেবে দেখে, যা নিজের ডেটাবেসেই সাথে সাথে কমিট হয়ে যায় — কোনো লক ধরে রাখা লাগে না। যদি কোনো পরের ধাপ ব্যর্থ হয়, তাহলে ইতিমধ্যে সম্পন্ন ধাপগুলোর compensating transactionCompensating Transactionএকটি নির্দিষ্ট সম্পন্ন ধাপের প্রভাব বাতিল করার জন্য ডিজাইন করা একটি বিপরীত অপারেশন — যেমন "ইনভেন্টরি রিজার্ভ করো"-এর কম্পেনসেশন হলো "রিজার্ভেশন ছেড়ে দাও"। উল্টো ক্রমে চালিয়ে সিস্টেমকে একটি সঙ্গতিপূর্ণ অবস্থায় ফিরিয়ে আনা হয়।

৩ · Choreography বনাম Orchestration

৪ · Python দিয়ে অরকেস্ট্রেশন-স্টাইল সাগা ইমপ্লিমেন্ট করা

নিচের কোডে প্রতিটি ধাপ একটি (step_function, compensating_function) জোড়া হিসেবে সংজ্ঞায়িত। অরকেস্ট্রেটর ধাপগুলো ক্রমান্বয়ে চালায়; কোনো ধাপ ব্যর্থ হলে ইতিমধ্যে সম্পন্ন ধাপগুলোর কম্পেনসেশন উল্টো ক্রমে চালানো হয়।

log = []

def reserve_inventory():
    log.append("ধাপ ১: reserve_inventory -> সফল")
    return True

def release_inventory():
    log.append("কম্পেনসেশন ১: release_inventory -> সফল (পণ্য স্টকে ফেরত)")

def charge_payment():
    log.append("ধাপ ২: charge_payment -> ব্যর্থ (অপর্যাপ্ত ব্যালেন্স)")
    return False

def refund_payment():
    log.append("কম্পেনসেশন ২: refund_payment -> সফল")

def confirm_order():
    log.append("ধাপ ৩: confirm_order -> সফল")
    return True

def cancel_order():
    log.append("কম্পেনসেশন ৩: cancel_order -> সফল")


# প্রতিটি এন্ট্রি: (স্টেপ ফাংশন, তার কম্পেনসেটিং ফাংশন)
order_saga = [
    (reserve_inventory, release_inventory),
    (charge_payment,   refund_payment),
    (confirm_order,    cancel_order),
]

def run_saga(steps):
    completed = []
    for step, compensate in steps:
        success = step()
        if not success:
            log.append("-> সাগা ব্যর্থ! ইতিমধ্যে সম্পন্ন ধাপগুলোর কম্পেনসেশন উল্টো ক্রমে চালানো হচ্ছে:")
            for _, comp in reversed(completed):
                comp()
            return False
        completed.append((step, compensate))
    log.append("-> সাগা সফলভাবে সম্পন্ন")
    return True


result = run_saga(order_saga)

print("=== Saga Execution Log ===")
for line in log:
    print(line)
print()
print("চূড়ান্ত ফলাফল:", "SUCCESS" if result else "ROLLED BACK (compensated)")

৫ · SAGA-এর ট্রেড-অফ

SAGA 2PC-এর মতো কড়া atomicity ও isolation দেয় না — ধাপ ১ ও ২-এর মাঝামাঝি সময়ে অন্য কোনো প্রক্রিয়া হয়তো "পণ্য রিজার্ভড কিন্তু পেমেন্ট এখনও হয়নি" এমন একটি মধ্যবর্তী অবস্থা দেখতে পারে। বিনিময়ে SAGA কোনো লক ধরে রাখে না, তাই প্রতিটি সার্ভিস স্বাধীনভাবে availability ও scalability বজায় রাখতে পারে। বাস্তব সিস্টেমে compensating transaction ডিজাইন করা কঠিন হতে পারে বিশেষত যখন একটি ধাপের প্রভাব সম্পূর্ণভাবে বাতিলযোগ্য নয় (যেমন একটি ইমেইল পাঠানো ইতিমধ্যে হয়ে গেলে তা "ফেরত" নেওয়া যায় না) — এক্ষেত্রে একটি ক্ষমাপ্রার্থী নোটিফিকেশন পাঠানোই ব্যবহারিক কম্পেনসেশন হতে পারে।