Senior⏱ 14 دقیقه2 بخش · 4 نکته

مرور سریع Event-Driven Architecture

معماری‌ای که سرویس‌ها را از طریق انتشار و اشتراک رویداد، به‌جای فراخوانی مستقیم، به هم متصل می‌کند.

0 از 4 نکته مرور شد0٪

فقط نکات طلایی ⭐

فهرست بخش‌ها

مفاهیم پایه0/2
الگوها و چالش‌ها0/2

مفاهیم پایه0/2

Event، Producer و Consumer.

Event در برابر Command⭐ طلایی

Command درخواستی برای انجام کاری است و یک گیرندهٔ مشخص دارد («این کار را انجام بده»)؛ Event اعلام وقوع چیزی در گذشته است و می‌تواند صفر یا چند شنونده داشته باشد («این اتفاق افتاد»).

csharp\npublic record OrderPlacedEvent(Guid OrderId, DateTime PlacedAt);\n

💡 نکتهٔ مصاحبه:

نام رویداد باید همیشه زمان گذشته باشد (OrderPlaced نه PlaceOrder) — این نکته در مصاحبه معمولاً پرسیده می‌شود.

Producer، Broker و Consumerمهم

Producer رویداد را تولید و منتشر می‌کند، Message Broker (مثل RabbitMQ یا Kafka) آن را نگه می‌دارد و توزیع می‌کند، Consumer رویداد را دریافت و پردازش می‌کند.

الگوها و چالش‌ها0/2

ملاحظات عملی این معماری.

Eventual Consistency⭐ طلایی

چون سرویس‌ها به‌صورت Async از طریق رویداد هماهنگ می‌شوند، در یک بازهٔ زمانی کوتاه ممکن است داده در سرویس‌های مختلف ناهم‌خوان باشد تا همه رویداد را پردازش کنند.

⚠️ اشتباه رایج:

انتظار سازگاری فوری (Strong Consistency) بین سرویس‌ها در یک معماری رویداد-محور — این تناقض ذاتی معماری است.

Idempotency در پردازش رویداد⭐ طلایی

چون پیام ممکن است به‌دلیل Retry بیش از یک‌بار به Consumer برسد، پردازش رویداد باید Idempotent باشد (اجرای چندباره همان نتیجهٔ اجرای یک‌بار را بدهد).

csharp\nif (await _db.ProcessedEvents.AnyAsync(e => e.Id == evt.Id)) return;\n

⚠️ اشتباه رایج:

فرض‌کردن اینکه هر پیام دقیقاً یک‌بار (Exactly-once) تحویل داده می‌شود؛ بیشتر Brokerها فقط At-least-once تضمین می‌کنند.