الگوی Saga: پیاده‌سازی تراکنش‌های توزیع‌شده برای میکروسرویس‌ها

در دنیای میکروسرویس‌ها، حفظ سازگاری داده‌ها در چندین سرویس می‌تواند یک چالش بزرگ باشد. تراکنش‌های سنتی ACID (اتمیسیته، سازگاری، ایزوله‌سازی، دوام) که معمولاً در برنامه‌های یکپارچه (monolithic) استفاده می‌شوند، اغلب برای محیط‌های توزیع‌شده مناسب نیستند. اینجاست که الگوی Saga وارد می‌شود و راه‌حلی قوی برای مدیریت تراکنش‌های توزیع‌شده و تضمین یکپارچگی داده‌ها در میان میکروسرویس‌ها ارائه می‌دهد.

الگوی Saga چیست؟

الگوی Saga یک الگوی طراحی است که برای مدیریت دنباله‌ای از تراکنش‌های محلی در چندین میکروسرویس استفاده می‌شود. این الگو راهی برای دستیابی به سازگاری نهایی (eventual consistency) فراهم می‌کند، به این معنی که اگرچه داده‌ها ممکن است به طور موقت ناسازگار باشند، اما در نهایت به یک وضعیت سازگار می‌رسند. به جای اتکا به یک تراکنش اتمی واحد که چندین سرویس را در بر می‌گیرد، الگوی Saga تراکنش را به مجموعه‌ای از تراکنش‌های کوچکتر و مستقل تقسیم می‌کند که هر کدام توسط یک سرویس واحد انجام می‌شود.

هر تراکنش محلی در یک Saga، پایگاه داده یک میکروسرویس واحد را به‌روزرسانی می‌کند. اگر یکی از تراکنش‌ها با شکست مواجه شود، Saga مجموعه‌ای از تراکنش‌های جبرانی (compensating transactions) را برای خنثی کردن تغییرات ایجاد شده توسط تراکنش‌های قبلی اجرا می‌کند و در عمل، کل عملیات را به عقب برمی‌گرداند (rollback).

چرا از الگوی Saga استفاده کنیم؟

عوامل متعددی الگوی Saga را به ابزاری ارزشمند برای مدیریت تراکنش‌ها در معماری میکروسرویس تبدیل می‌کنند:

• جداسازی (Decoupling): الگوی Saga اتصال ضعیف (loose coupling) بین میکروسرویس‌ها را ترویج می‌دهد و به آنها اجازه می‌دهد به طور مستقل و بدون تأثیر بر سایر سرویس‌ها تکامل یابند. این یک مزیت کلیدی در معماری میکروسرویس است.
• مقیاس‌پذیری (Scalability): با اجتناب از تراکنش‌های توزیع‌شده طولانی‌مدت، Sagaها مقیاس‌پذیری و عملکرد را بهبود می‌بخشند. هر میکروسرویس می‌تواند تراکنش‌های خود را به طور مستقل مدیریت کند که این امر باعث کاهش رقابت بر سر منابع و افزایش توان عملیاتی می‌شود.
• تاب‌آوری (Resilience): الگوی Saga برای تاب‌آوری در برابر شکست‌ها طراحی شده است. اگر یک تراکنش با شکست مواجه شود، Saga می‌تواند به عقب برگردانده شود، که از ناسازگاری داده‌ها جلوگیری کرده و تضمین می‌کند که سیستم در یک وضعیت سازگار باقی می‌ماند.
• انعطاف‌پذیری (Flexibility): الگوی Saga انعطاف‌پذیری لازم برای مدیریت فرآیندهای کسب‌وکار پیچیده‌ای که چندین سرویس را در بر می‌گیرند، فراهم می‌کند. این الگو به شما اجازه می‌دهد تا توالی تراکنش‌ها و اقدامات جبرانی را در صورت شکست تعریف کنید.

ACID در مقابل BASE

درک تفاوت بین ACID و BASE (Basically Available, Soft state, Eventually consistent) هنگام تصمیم‌گیری برای استفاده از الگوی Saga بسیار مهم است.

• ACID (اتمیسیته، سازگاری، ایزوله‌سازی، دوام): تضمین می‌کند که تراکنش‌ها به طور قابل اعتماد پردازش می‌شوند. اتمیسیته تضمین می‌کند که یا تمام عملیات درون یک تراکنش موفقیت‌آمیز هستند یا هیچ‌کدام. سازگاری تضمین می‌کند که یک تراکنش پایگاه داده را از یک وضعیت معتبر به وضعیت معتبر دیگری منتقل می‌کند. ایزوله‌سازی تضمین می‌کند که تراکنش‌های همزمان با یکدیگر تداخل ندارند. دوام تضمین می‌کند که پس از تایید (commit) یک تراکنش، حتی در صورت خرابی سیستم، باقی می‌ماند.
• BASE (اساساً در دسترس، وضعیت نرم، نهایتاً سازگار): این یک رویکرد متفاوت است که برای سیستم‌های توزیع‌شده طراحی شده است. اساساً در دسترس (Basically Available) به این معنی است که سیستم در بیشتر مواقع در دسترس است. وضعیت نرم (Soft state) به این معنی است که وضعیت سیستم ممکن است با گذشت زمان، حتی بدون ورودی، تغییر کند. نهایتاً سازگار (Eventually consistent) به این معنی است که سیستم پس از توقف دریافت ورودی، در نهایت سازگار خواهد شد. الگوی Saga با اصول BASE همخوانی دارد.

دو استراتژی اصلی پیاده‌سازی Saga

دو روش اصلی برای پیاده‌سازی الگوی Saga وجود دارد: هماهنگی مبتنی بر رویداد (Choreography) و ارکستراسیون (Orchestration).

۱. Saga مبتنی بر هماهنگی رویداد (Choreography)

در یک Saga مبتنی بر هماهنگی رویداد، هر میکروسرویس با گوش دادن به رویدادهای منتشر شده توسط میکروسرویس‌های دیگر و واکنش مناسب به آنها، در Saga شرکت می‌کند. هیچ ارکستراتور مرکزی وجود ندارد؛ هر سرویس مسئولیت‌های خود را می‌داند و می‌داند چه زمانی باید اقدامات خود را انجام دهد.

چگونه کار می‌کند:

1. Saga زمانی شروع می‌شود که یک میکروسرویس رویدادی را منتشر می‌کند که نشان‌دهنده شروع تراکنش است.
2. میکروسرویس‌های دیگر در این رویداد مشترک می‌شوند و پس از دریافت آن، تراکنش محلی خود را انجام می‌دهند.
3. پس از تکمیل تراکنش، هر میکروسرویس رویداد دیگری را منتشر می‌کند که موفقیت یا شکست عملیات خود را نشان می‌دهد.
4. میکروسرویس‌های دیگر به این رویدادها گوش می‌دهند و اقدامات مناسب را انجام می‌دهند، یا به مرحله بعدی Saga می‌روند یا در صورت بروز خطا، تراکنش‌های جبرانی را آغاز می‌کنند.

مثال: ثبت سفارش در فروشگاه آنلاین (Choreography)

1. سرویس سفارش: یک درخواست سفارش جدید دریافت کرده و رویداد `OrderCreated` را منتشر می‌کند.
2. سرویس موجودی: در رویداد `OrderCreated` مشترک می‌شود. پس از دریافت رویداد، موجودی را بررسی می‌کند. اگر کافی باشد، اقلام را رزرو کرده و رویداد `InventoryReserved` را منتشر می‌کند. اگر کافی نباشد، رویداد `InventoryReservationFailed` را منتشر می‌کند.
3. سرویس پرداخت: در رویداد `InventoryReserved` مشترک می‌شود. پس از دریافت رویداد، پرداخت را پردازش می‌کند. اگر موفقیت‌آمیز باشد، رویداد `PaymentProcessed` را منتشر می‌کند. اگر شکست بخورد، رویداد `PaymentFailed` را منتشر می‌کند.
4. سرویس ارسال: در رویداد `PaymentProcessed` مشترک می‌شود. پس از دریافت رویداد، محموله را آماده کرده و رویداد `ShipmentPrepared` را منتشر می‌کند.
5. سرویس سفارش: در رویداد `ShipmentPrepared` مشترک می‌شود. پس از دریافت رویداد، سفارش را به عنوان تکمیل‌شده علامت‌گذاری می‌کند.
6. جبران (Compensation): اگر رویداد `PaymentFailed` یا `InventoryReservationFailed` منتشر شود، سرویس‌های دیگر گوش می‌دهند و تراکنش‌های جبرانی را انجام می‌دهند (مانند آزاد کردن موجودی رزرو شده).

مزایای Choreography:

• سادگی: پیاده‌سازی آن برای گردش‌های کاری ساده، آسان‌تر است.
• غیرمتمرکز: اتصال ضعیف و تکامل مستقل میکروسرویس‌ها را ترویج می‌دهد.

معایب Choreography:

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

۲. Saga مبتنی بر ارکستراسیون (Orchestration)

در یک Saga مبتنی بر ارکستراسیون، یک ارکستراتور مرکزی (که اغلب به عنوان یک سرویس اختصاصی یا یک ماشین حالت پیاده‌سازی می‌شود) Saga را مدیریت کرده و اجرای تراکنش‌های محلی توسط میکروسرویس‌های شرکت‌کننده را هماهنگ می‌کند. ارکستراتور به هر سرویس می‌گوید چه کاری را و در چه زمانی انجام دهد.

چگونه کار می‌کند:

1. Saga زمانی شروع می‌شود که یک کلاینت از ارکستراتور درخواست آغاز تراکنش را می‌کند.
2. ارکستراتور دستوراتی را به میکروسرویس‌های شرکت‌کننده برای انجام تراکنش‌های محلی‌شان ارسال می‌کند.
3. هر میکروسرویس تراکنش خود را انجام داده و موفقیت یا شکست آن را به ارکستراتور اطلاع می‌دهد.
4. بر اساس نتیجه، ارکستراتور تصمیم می‌گیرد که به مرحله بعدی برود یا تراکنش‌های جبرانی را آغاز کند.

مثال: ثبت سفارش در فروشگاه آنلاین (Orchestration)

1. ارکستراتور سفارش: یک درخواست سفارش جدید دریافت می‌کند.
2. ارکستراتور سفارش: دستوری به سرویس موجودی برای رزرو اقلام ارسال می‌کند.
3. سرویس موجودی: اقلام را رزرو کرده و به ارکستراتور سفارش اطلاع می‌دهد.
4. ارکستراتور سفارش: دستوری به سرویس پرداخت برای پردازش پرداخت ارسال می‌کند.
5. سرویس پرداخت: پرداخت را پردازش کرده و به ارکستراتور سفارش اطلاع می‌دهد.
6. ارکستراتور سفارش: دستوری به سرویس ارسال برای آماده‌سازی محموله ارسال می‌کند.
7. سرویس ارسال: محموله را آماده کرده و به ارکستراتور سفارش اطلاع می‌دهد.
8. ارکستراتور سفارش: سفارش را به عنوان تکمیل‌شده علامت‌گذاری می‌کند.
9. جبران (Compensation): اگر هر مرحله‌ای با شکست مواجه شود، ارکستراتور سفارش دستورات جبرانی را به سرویس‌های مربوطه ارسال می‌کند (مانند آزاد کردن موجودی رزرو شده).

مزایای Orchestration:

• کنترل متمرکز: مدیریت و نظارت بر Saga از یک نقطه مرکزی آسان‌تر است.
• قابلیت مشاهده بهبود یافته: ارکستراتور دید واضحی از پیشرفت کلی و وضعیت Saga فراهم می‌کند.
• کاهش اتصال: میکروسرویس‌ها فقط نیاز به ارتباط با ارکستراتور دارند، که وابستگی‌های مستقیم بین آنها را کاهش می‌دهد.

معایب Orchestration:

• پیچیدگی: پیاده‌سازی اولیه آن، به خصوص برای گردش‌های کاری ساده، می‌تواند پیچیده‌تر باشد.
• نقطه تکی شکست (Single Point of Failure): ارکستراتور می‌تواند به یک نقطه تکی شکست تبدیل شود، اگرچه این مشکل را می‌توان با افزونگی و اقدامات تحمل‌پذیری خطا کاهش داد.

پیاده‌سازی تراکنش‌های جبرانی

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

ملاحظات کلیدی برای تراکنش‌های جبرانی:

• هم‌توانی (Idempotency): تراکنش‌های جبرانی باید هم‌توان باشند، به این معنی که اجرای چندباره آنها نتیجه را تغییر ندهد. این امر مهم است زیرا شکست‌ها ممکن است در هر نقطه‌ای رخ دهند و تراکنش جبرانی ممکن است دوباره امتحان شود.
• مدیریت شکست‌ها: تراکنش‌های جبرانی نیز می‌توانند با شکست مواجه شوند. شما باید یک استراتژی برای مدیریت شکست در تراکنش‌های جبرانی داشته باشید، مانند تلاش مجدد، ثبت خطاها و هشدار به مدیران سیستم.
• سازگاری داده‌ها: تراکنش‌های جبرانی باید تضمین کنند که داده‌ها سازگار باقی می‌مانند. این ممکن است شامل بازگرداندن داده‌ها به وضعیت قبلی، حذف داده‌های تازه ایجاد شده، یا به‌روزرسانی داده‌ها برای منعکس کردن لغو تراکنش باشد.

مثال‌هایی از تراکنش‌های جبرانی:

• سرویس موجودی: اگر سرویس موجودی اقلامی را رزرو کرده باشد اما پرداخت با شکست مواجه شود، تراکنش جبرانی، آزاد کردن اقلام رزرو شده خواهد بود.
• سرویس پرداخت: اگر سرویس پرداخت، پرداختی را پردازش کرده باشد اما ارسال با شکست مواجه شود، تراکنش جبرانی ممکن است شامل صدور بازپرداخت وجه باشد.

چالش‌ها و ملاحظات

در حالی که الگوی Saga مزایای قابل توجهی ارائه می‌دهد، چالش‌ها و ملاحظاتی نیز به همراه دارد:

• پیچیدگی: پیاده‌سازی الگوی Saga می‌تواند پیچیده باشد، به خصوص برای فرآیندهای کسب‌وکار پیچیده. برنامه‌ریزی و طراحی دقیق ضروری است.
• سازگاری نهایی: الگوی Saga سازگاری نهایی را فراهم می‌کند، به این معنی که داده‌ها ممکن است به طور موقت ناسازگار باشند. این می‌تواند برای برنامه‌هایی که به تضمین‌های سازگاری قوی نیاز دارند، یک نگرانی باشد.
• تست: تست کردن Sagaها به دلیل ماهیت توزیع‌شده و پتانسیل شکست در نقاط مختلف، می‌تواند چالش‌برانگیز باشد.
• نظارت (Monitoring): نظارت بر پیشرفت و وضعیت Sagaها برای شناسایی و حل مشکلات بسیار مهم است. شما باید ابزارها و فرآیندهای نظارتی مناسبی داشته باشید.
• هم‌توانی (Idempotency): اطمینان از هم‌توان بودن تراکنش‌ها و تراکنش‌های جبرانی برای جلوگیری از ناسازگاری داده‌ها حیاتی است.
• ایزوله‌سازی (Isolation): از آنجایی که Sagaها شامل چندین تراکنش محلی هستند، ایزوله‌سازی می‌تواند یک نگرانی باشد. استراتژی‌هایی مانند قفل‌های معنایی (semantic locks) یا قفل‌گذاری خوش‌بینانه (optimistic locking) ممکن است مورد نیاز باشد.

موارد استفاده و مثال‌ها

الگوی Saga برای موارد استفاده متنوعی، به ویژه در سیستم‌های توزیع‌شده و معماری میکروسرویس، بسیار مناسب است. در اینجا چند مثال رایج آورده شده است:

• مدیریت سفارش در فروشگاه آنلاین: همانطور که در مثال‌های بالا نشان داده شد، الگوی Saga می‌تواند برای مدیریت کل چرخه عمر سفارش، از ایجاد سفارش گرفته تا پردازش پرداخت و ارسال، استفاده شود.
• تراکنش‌های مالی: الگوی Saga می‌تواند برای مدیریت تراکنش‌های مالی پیچیده‌ای که شامل چندین سیستم هستند، مانند انتقال وجه، درخواست وام و مطالبات بیمه، استفاده شود.
• مدیریت زنجیره تأمین: الگوی Saga می‌تواند برای هماهنگ کردن فعالیت‌ها بین چندین نهاد در یک زنجیره تأمین، مانند تولیدکنندگان، توزیع‌کنندگان و خرده‌فروشان، استفاده شود.
• سیستم‌های بهداشتی و درمانی: الگوی Saga می‌تواند برای مدیریت سوابق بیماران و هماهنگی مراقبت بین بخش‌ها و ارائه‌دهندگان مختلف استفاده شود.

مثال: تراکنش بانکی جهانی

سناریویی را تصور کنید که شامل یک تراکنش بانکی جهانی بین دو بانک مختلف واقع در کشورهای مختلف است که تحت قوانین و بررسی‌های انطباق متفاوتی قرار دارند. الگوی Saga می‌تواند تضمین کند که تراکنش مراحل تعریف‌شده را دنبال می‌کند:

1. آغاز تراکنش: مشتری انتقال وجهی را از حساب خود در بانک A (واقع در آمریکا) به حساب گیرنده در بانک B (واقع در آلمان) آغاز می‌کند.
2. بانک A - اعتبارسنجی حساب: بانک A حساب مشتری را اعتبارسنجی می‌کند، موجودی کافی را بررسی می‌کند و اطمینان حاصل می‌کند که هیچ محدودیتی روی حساب وجود ندارد.
3. بررسی انطباق (بانک A): بانک A یک بررسی انطباق را برای اطمینان از عدم نقض مقررات ضد پولشویی (AML) یا تحریم‌های بین‌المللی انجام می‌دهد.
4. انتقال وجه (بانک A): بانک A از حساب مشتری پول برداشت کرده و وجوه را به یک مرکز پایاپای یا بانک واسط ارسال می‌کند.
5. پردازش در مرکز پایاپای: مرکز پایاپای تراکنش را پردازش می‌کند، تبدیل ارز (USD به EUR) را انجام می‌دهد و وجوه را به بانک B هدایت می‌کند.
6. بانک B - اعتبارسنجی حساب: بانک B حساب گیرنده را اعتبارسنجی کرده و اطمینان حاصل می‌کند که فعال است و واجد شرایط دریافت وجه است.
7. بررسی انطباق (بانک B): بانک B بررسی انطباق خود را با رعایت مقررات آلمان و اتحادیه اروپا انجام می‌دهد.
8. واریز به حساب (بانک B): بانک B وجه را به حساب گیرنده واریز می‌کند.
9. تأیید: بانک B یک پیام تأیید به بانک A ارسال می‌کند، که سپس به مشتری اطلاع می‌دهد که تراکنش تکمیل شده است.

تراکنش‌های جبرانی:

• اگر بررسی انطباق در بانک A با شکست مواجه شود، تراکنش لغو می‌شود و از حساب مشتری پولی برداشت نمی‌شود.
• اگر بررسی انطباق در بانک B با شکست مواجه شود، وجوه به بانک A بازگردانده می‌شود و به حساب مشتری واریز می‌گردد.
• اگر مشکلی در تبدیل ارز یا مسیریابی در مرکز پایاپای وجود داشته باشد، تراکنش معکوس شده و وجوه به بانک A بازگردانده می‌شود.

ابزارها و فناوری‌ها

ابزارها و فناوری‌های متعددی می‌توانند در پیاده‌سازی الگوی Saga کمک کنند:

• صف‌های پیام: Apache Kafka, RabbitMQ و Amazon SQS می‌توانند برای انتشار و اشتراک رویدادها در یک Saga مبتنی بر Choreography استفاده شوند.
• موتورهای گردش کار: Camunda, Zeebe و Apache Airflow می‌توانند برای پیاده‌سازی ارکستراتورها و مدیریت گردش‌های کاری پیچیده استفاده شوند.
• منبع‌یابی رویداد (Event Sourcing): منبع‌یابی رویداد می‌تواند برای ردیابی تاریخچه رویدادها در یک Saga و تسهیل بازگشت به عقب در صورت شکست استفاده شود.
• مدیران تراکنش توزیع‌شده: برخی از مدیران تراکنش توزیع‌شده، مانند Atomikos، می‌توانند برای هماهنگی تراکنش‌ها در چندین سرویس استفاده شوند. با این حال، به دلیل محدودیت‌های ذاتی آنها در محیط‌های توزیع‌شده، ممکن است برای همه معماری‌های میکروسرویس مناسب نباشند.
• فریم‌ورک‌های Saga: همچنین فریم‌ورک‌های Saga وجود دارند که انتزاعات و ابزارهایی برای پیاده‌سازی الگوی Saga فراهم می‌کنند.

بهترین شیوه‌ها برای پیاده‌سازی الگوی Saga

برای پیاده‌سازی مؤثر الگوی Saga، بهترین شیوه‌های زیر را در نظر بگیرید:

• طراحی دقیق: نیازمندی‌های کسب‌وکار خود را به طور کامل تحلیل کرده و Saga را بر اساس آن طراحی کنید. میکروسرویس‌های شرکت‌کننده، توالی تراکنش‌ها و اقدامات جبرانی را مشخص کنید.
• هم‌توانی (Idempotency): اطمینان حاصل کنید که تمام تراکنش‌ها و تراکنش‌های جبرانی هم‌توان هستند.
• مدیریت خطا: مکانیزم‌های قوی مدیریت خطا را برای مقابله با شکست‌ها در هر نقطه از Saga پیاده‌سازی کنید.
• نظارت و ثبت وقایع (Logging): نظارت و ثبت وقایع جامع را برای ردیابی پیشرفت و وضعیت Sagaها پیاده‌سازی کنید.
• تست: Sagaهای خود را به طور کامل تست کنید تا از عملکرد صحیح آنها و مدیریت مناسب شکست‌ها اطمینان حاصل کنید.
• قفل‌های معنایی (Semantic Locks): قفل‌های معنایی را برای جلوگیری از به‌روزرسانی‌های همزمان روی داده‌های یکسان توسط Sagaهای مختلف پیاده‌سازی کنید.
• قفل‌گذاری خوش‌بینانه (Optimistic Locking): از قفل‌گذاری خوش‌بینانه برای شناسایی و جلوگیری از تداخل بین تراکنش‌های همزمان استفاده کنید.
• انتخاب استراتژی پیاده‌سازی مناسب: مزایا و معایب بین Choreography و Orchestration را به دقت در نظر بگیرید و استراتژی‌ای را انتخاب کنید که به بهترین وجه با نیازهای شما مطابقت دارد.
• تعریف سیاست‌های جبرانی واضح: سیاست‌های روشنی برای مدیریت جبران تعریف کنید، از جمله شرایطی که جبران فعال می‌شود و اقدامات خاصی که باید انجام شود.

نتیجه‌گیری

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

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