A Single Consumer Solves Ordering But Limits Scale
یک Consumer واحد ترتیب رو حل می‌کنه، اما مقیاس‌پذیری رو محدود می‌کنه ⚖️

یک consumer یعنی:
• سقف throughput (فقط یک worker) 🧱
• افزایش latency زیر load بالا 🐢
• ءscaling عمودی می‌شه، نه افقی 📏

حتی اگر eventها سبک باشن، شما به‌صورت مصنوعی کل سیستم رو bottleneck کردید. 🚧

پس ما می‌خوایم:
ترتیب به‌ازای هر aggregate 🔗
مقیاس‌پذیری افقی 🧩
قابلیت اطمینان (Outbox همچنان باقی می‌مونه) 📦

اینجاست که تیم‌ها معمولاً «مرحله‌ی بعدی» رو اختراع می‌کنن. 💡

Publish the Next Message From the Handler
پیام بعدی رو از داخل Handler منتشر کن 📤

اگه competing consumerها ترتیب رو می‌شکنن، یک ایده‌ی طبیعی اینه:
👉 نذاریم queue تصمیم بگیره پیام بعدی چیه، خودمون تصمیم بگیریم.

به‌جای این‌که همه‌ی eventها رو بریزیم تو queue و بذاریم consumerها با هم race کنن،‌می‌ریم سراغ یک مدل زنجیره‌ای:
🔹️یک پیام برای یک aggregate رو handle کن
🔹️وقتی تموم شد، پیام بعدی رو publish کن
🔹️تا step بعدی اجرا بشه

حالا سیستم برای هر aggregate در هر لحظه فقط یک پیام رو پردازش می‌کنه. 🧵

و این لحظه‌ی کلیدیه:

🚨 شما دیگه «event handler» نمی‌سازید.
شما دارید workflow می‌سازید.

و اسم اون workflow چیه؟ 👉 یک Saga.

Congratulations, You Built a Choreographed Saga
تبریک! تو یک Saga کُریوگرافی‌شده ساختی 🎭

یک choreographed saga یعنی:

• هر step به یک event واکنش نشون می‌ده
• یک کاری انجام می‌ده
• ءevent بعدی رو منتشر می‌کنه تا step بعدی شروع بشه
• هیچ coordinator مرکزی وجود نداره.

در عوض، یک زنجیره داریم:
«وقتی X اتفاق افتاد، Y رو انجام بده، بعد Z رو publish کن»

این الگو دقیقاً با نیاز جدیدت فیت می‌شه:
🔹️ترتیب به‌ازای هر aggregate حفظ می‌شه (زنجیره‌ای) 🔗
🔸️می‌تونی روی aggregateهای مختلف scale کنی (چندین زنجیره هم‌زمان) 🧩
🔹️هر step ایزوله و قابل retry هست ♻️

و یک دیسیپلین مفید هم تحمیل می‌کنه:
• «قدم بعدی چیه؟» صریح و شفاف می‌شه
• مرز بین stepها واضح‌تر می‌شه
• می‌تونی کل workflow رو به‌صورت یک sequence مشاهده کنی 👀

اما choreography یک محدودیت داره:
کنترل پخش شده است،
پس track کردن پیشرفت و مدیریت خطاها می‌تونه کثیف بشه. 🧨

پس می‌ریم سراغ قدم نهایی.

If You Want Control, Introduce a State Machine Saga
اگر کنترل می‌خوای، Saga مبتنی بر State Machine بساز 🧠

وقتی workflow مهم می‌شه، معمولاً این‌ها رو می‌خوای:

🔸️یک جای واحد که state فعلی رو بدونه 🗂
🔸️دید روی پیشرفت («کجا گیر کردیم؟») 🔍
🔸️ءtimeout و retry صریح ⏳
🔸️اکشن جبرانی وقتی چیزی fail می‌شه 🔄

اینجاست که از choreography می‌ری به سمت orchestration
با استفاده از یک state machine saga:

🔹️ءsaga وضعیت workflow رو نگه می‌داره
🔹️ءeventها transitionها رو جلو می‌برن
🔹️ءsaga تصمیم می‌گیره پیام بعدی چی باشه

تو این مدل، کنترل و observability رو به دست میاری. 🎛

و نکته‌ی مهم:
🔸️این جای Outbox رو نمی‌گیره.
🔸️📦 تو هنوز به انتشار قابل‌اعتماد نیاز داری.
🔸️تو فقط workflow رو explicit کردی.