بعد یک Worker، Event را از Outbox خوانده و به Broker منتشر می‌کند.
در نتیجه، دیگر به این شکل نیست که:
«اول Order را ذخیره کنیم و امیدوار باشیم بعداً Publish هم موفق شود.»
🎯 یک قانون ساده برای System Design
قبل از اینکه بگویید:
RabbitMQ
یا
Kafka
یا
gRPC
یا
Redis
یا هر تکنولوژی دیگری...
ابتدا این سه سؤال را بپرسید:
1️⃣ اگر این عملیات Fail شود، آیا Business Transaction باید Fail شود؟
اگر بله → احتمالاً Synchronous / Critical Path
اگر نه → احتمالاً می‌تواند Asynchronous شود.
2️⃣ آیا Consumer باید بلافاصله نتیجه را پردازش کند یا فقط باید از اتفاق رخ‌داده مطلع شود؟
این سؤال به شما کمک می‌کند بین Command-oriented Messaging و Event-oriented Communication تصمیم بگیرید.
3️⃣ آیا به قابلیت‌هایی مثل Retention، چند Consumer مستقل، Replay و Stream Processing نیاز دارید؟
اگر بله، انتخاب‌هایی مثل Kafka جدی‌تر می‌شوند.
🚀 در نهایت...
به نظرم یکی از مهم‌ترین مهارت‌های System Design این نیست که بتوانی ده‌ها تکنولوژی را نام ببری.
مهم‌تر این است که بتوانی تشخیص بدهی:
کدام عملیات واقعاً باید همین الان انجام شود؟
و کدام عملیات می‌تواند چند ثانیه بعد انجام شود، بدون اینکه Business Rule اصلی سیستم نقض شود؟
وقتی این مرز را درست مشخص کردی، انتخاب تکنولوژی خیلی ساده‌تر می‌شود.
چون آن موقع دیگر نمی‌پرسی:
❌ Kafka یا RabbitMQ؟
بلکه می‌پرسی:
✅ ءBusiness من چه نوع Communication Patternای نیاز دارد؟
و این دقیقاً جایی است که System Design از انتخاب تکنولوژی جدا می‌شود.