الگوی ساگا

Saga Pattern یا دیزاین پترن ساگا، الگوی مدیریت یک فرایند تجاری چندمرحله‌ای در سیستم توزیع‌شده است. تفاوت کلیدی آن با تراکنش تک‌دیتابیسی، Commit شدن مستقل هر مرحله است. بنابراین هنگام شکست، هماهنگ‌کننده یا سرویس‌ها باید اقدام‌های جبرانی را شروع کنند، نه اینکه انتظار Rollback خودکار میان همه دیتابیس‌ها را داشته باشند.

طراحی ساگا از صفر

ساگا مبتنی بر رویداد یا هماهنگ‌کننده؟

در Orchestration یک هماهنگ‌کننده مرکزی، وضعیت مراحل را نگه می‌دارد و فرمان مرحله بعد را ارسال می‌کند. در Choreography هر سرویس به رویداد سرویس قبلی گوش می‌دهد و بدون هماهنگ‌کننده مرکزی پیش می‌رود. روش اول مشاهده و عیب‌یابی جریان‌های طولانی را آسان‌تر می‌کند، روش دوم وابستگی به یک هماهنگ‌کننده مشترک را کاهش می‌دهد، ولی با زیاد شدن رویدادها پیچیده می‌شود.

شبه‌کد مدیریت شکست

# Educational pseudocode: each action calls a real service API.
def place_order(order_id):
    compensated = []
    try:
        inventory.reserve(order_id)
        compensated.append(lambda: inventory.release(order_id))

        payment.charge(order_id)
        compensated.append(lambda: payment.refund(order_id))

        delivery.schedule(order_id)
        return "confirmed"
    except ServiceError:
        for compensate in reversed(compensated):
            enqueue_with_retry(compensate)  # never silently ignore errors
        return "compensation_pending"

پرسش‌های ضروری پیش از اجرای ساگا

این شبه‌کد فقط منطق تصمیم‌گیری را نمایش می‌دهد. در محیط واقعی، وضعیت ساگا و شناسه همبستگی باید پایدار ذخیره شوند، اقدام‌های جبرانی در صف پردازش شوند و پس از ری‌استارت نیز ادامه پیدا کنند. از الگوی صندوق خروجی تراکنشی برای هماهنگی ثبت داده و ارسال رویداد کمک می‌گیرند. هر مرحله باید آیدمپوتنسی باشد تا اجرای دوباره پیام باعث دوبار کسر وجه یا دوبار رزرو نشود.

اصطلاحات فنی: ساگا، اسید، میکروسرویس، مسیج بروکر، الگوی صندوق خروجی تراکنشی.