‏آشنایی با الگوی Outbox

نویسنده تو این یادداشتِ کوتاه می‌گه تازه با الگوی Outbox آشنا شده و این الگو یه مشکلِ خیلی رایج رو حل می‌کنه. یه سیستمی رو تصور کن که یه سفارش رو پردازش می‌کنه و بعدش یه ایمیل می‌فرسته؛ پرداخت، پردازش سفارش و ارسال ایمیل همه تو یه تراکنشِ دیتابیس اتفاق می‌افتن و اگه هرکدوم شکست بخوره، همه‌چی rollback می‌شه.

سؤالِ اصلی اینه: وقتی پرداخت و سفارش موفق شدن، باید منتظر بمونیم تا ایمیل هم فرستاده بشه و بعد تراکنش رو موفق اعلام کنیم؟ و اگه ارسال ایمیل شکست خورد، واقعاً باید پرداخت و سفارش رو هم برگردونیم؟ گره‌خوردنِ این کارهای جدا به هم، سیستم رو شکننده می‌کنه.

راه‌حل، همون الگوی Outboxه: به‌جای فرستادنِ ایمیل داخل تراکنش، پیامِ ایمیل رو تو یه جدولِ جدا به اسم outbox ثبت می‌کنی. بعد یه پروسهٔ مستقل اون پیام رو برمی‌داره و با retryهای لازم و رعایتِ idempotency (یعنی اگه چندبار اجرا شد، نتیجه‌ش عوض نشه) منتشرش می‌کنه.

به گفتهٔ نویسنده، همین توضیح می‌ده که چرا کاربر می‌تونه حتی وقتی مثلاً سرویس‌دهندهٔ ایمیل آفلاینه، بازم سفارشش رو ثبت کنه — چون دیگه این دوتا در لحظه به هم وابسته نیستن. نویسنده برای عمیق‌تر شدن به توضیحاتِ سایت Microservices.io ارجاع می‌ده.

نکات کلیدی:

• الگوی Outbox کارهای جانبی مثل ارسال ایمیل رو از تراکنشِ اصلیِ دیتابیس جدا می‌کنه.
• پیام به‌جای ارسال مستقیم، تو یه جدول outbox ثبت می‌شه.
• یه پروسهٔ جدا پیام رو با retry و idempotency منتشر می‌کنه.
• نتیجه اینه که سفارش و ایمیل دیگه در لحظه به هم وابسته نیستن و سیستم مقاوم‌تر می‌شه.