4️⃣ Outbox Pattern 📤📦(بخش چهارم)
ءOutbox Pattern با ذخیره‌کردن Eventها در یک جدول دیتابیس (Outbox) در همان Transaction تغییرات داده‌های بیزینسی، انتشار قابل‌اعتماد Eventها را تضمین می‌کند.
سپس یک فرآیند جداگانه، Eventها را از Outbox خوانده و به Message Broker منتشر می‌کند.
به این شکل تضمین می‌شود که Eventها اگر و فقط اگر Transaction بیزینسی موفق باشد منتشر شوند.
🔧 How it works:
🔹️وقتی یک سرویس داده بیزینسی را تغییر می‌دهد، هم‌زمان رکورد Event را در جدول Outbox و در همان Transaction دیتابیس درج می‌کند
🔸️ءTransaction دیتابیس، Atomicity بین تغییر داده و ایجاد Event را تضمین می‌کند
🔹️یک فرآیند Background یا Worker به‌صورت مداوم جدول Outbox را برای Eventهای منتشرنشده بررسی می‌کند
🔸️این فرآیند Eventها را خوانده و به Message Broker ارسال می‌کند
🔹️بعد از انتشار موفق، Event به‌عنوان پردازش‌شده علامت‌گذاری یا از Outbox حذف می‌شود
🔸️اگر انتشار شکست بخورد، Event در Outbox باقی می‌ماند و به‌صورت خودکار Retry می‌شود
🔹️این الگو مشکل Dual-Write (ذخیره داده موفق، اما انتشار Event ناموفق) را حذف می‌کند
🔸️ءEventها حداقل یک‌بار (At-Least-Once) منتشر می‌شوند و Consumerها باید Duplicateها را مدیریت کنند
✅ Benefits:
• تضمین می‌کند Eventها فقط در صورت موفقیت Transaction بیزینسی منتشر شوند
• مشکل Dual-Write بین دیتابیس و Message Broker را به‌طور کامل حذف می‌کند
• یک Audit Trail قابل‌اعتماد از تمام Eventهای سیستم در دیتابیس فراهم می‌کند
• امکان Event Replay و Recovery با نگه‌داشتن تاریخچه Eventها
❌ Drawbacks:
• ایجاد Eventual Consistency چون Eventها بلافاصله منتشر نمی‌شوند و Polling دارند
• نیاز به زیرساخت اضافی برای Outbox Processor و مانیتورینگ آن
• ایجاد سربار عملکردی به‌دلیل نوشتن‌های اضافی در دیتابیس و Polling
• نیاز به مدیریت Duplicate Eventها در Consumer (می‌توان از InBox Pattern + Idempotence استفاده کرد)
🎯 Use cases:
🔹️ءMicroservices که باید انتشار Event بعد از تغییر داده‌ها را قطعاً تضمین کنند
🔹️سیستم‌های Event Sourcing که هر تغییر وضعیت باید به‌عنوان Event ثبت شود
🔹️هر سناریویی که Consistency بین سرویس‌ها حیاتی است و از دست رفتن پیام غیرقابل‌قبول است