معماری رویداد-محور؛ وقتی سرویس‌ها به‌جای «دستور دادن» به هم «خبر می
‌دن»
در معماری‌های سنتی، سرویس‌ها مستقیم با هم صحبت می‌کنن:
سرویس سفارش، سرویس انبار رو صدا می‌زنه، انبار هم سرویس ارسال رو... یعنی وابستگی زنجیره‌ای؛ اگه یکی از حلقه‌ها کند یا خراب بشه، کل زنجیره می‌لنگه.

در Event-Driven Architecture (EDA) این رابطه عوض می‌شه. سرویس‌ها به‌جای صدا زدن مستقیم هم، فقط «رویداد» (event) منتشر می‌کنن؛ مثلاً وقتی سفارشی ثبت می‌شه، سرویس سفارش یه رویداد OrderPlaced رو روی یه message broker (مثل Kafka یا NATS) پابلیش می‌کنه. هر سرویسی که به این خبر نیاز داره (انبار، پرداخت، اعلان) بهش subscribe می‌کنه و مستقل از بقیه واکنش نشون می‌ده.

مزیت اصلی‌اش decoupling واقعیه:
سرویس سفارش اصلاً نمی‌دونه چند تا سرویس دیگه به رویدادش گوش می‌دن، و می‌شه بدون تغییر کد قدیمی یه consumer جدید (مثلاً آنالیتیکس) اضافه کرد. مقیاس‌پذیری و تحمل خطا هم بهتره، چون اگه یه سرویس مصرف‌کننده موقتاً از کار بیفته، رویدادها توی broker می‌مونن و بعداً پردازش می‌شن.
نمونه ساده‌ش:

// وقتی سفارش ثبت میشه
publish("OrderPlaced", { orderId, userId, items })

// سرویس انبار
subscribe("OrderPlaced", (event) => {
  reserveInventory(event.items)
})

// سرویس اعلان
subscribe("OrderPlaced", (event) => {
  sendConfirmationEmail(event.userId)
})

نکته مهم: EDA پیچیدگی جدیدی هم میاره؛ دیباگ کردن جریان رویدادها سخت‌تره و باید به idempotency (جلوگیری از پردازش تکراری یه رویداد) و event ordering فکر کنی. برای سیستم‌های ساده شاید لازم نباشه؛ بیشتر برای میکروسرویس‌هایی که نیاز به مقیاس‌پذیری و استقلال بالا دارن مناسبه.

#معماری_نرم_افزار #برنامه_نویسی #میکروسرویس #EventDriven #Kafka

منابع:
• Event-Driven Architecture in 2026: Patterns, Tools, and When to Use It – Encore
• Event-Driven Architecture in 2026: Kafka, NATS, and Building Reactive Microservices | ZeonEdge

کانال آموزشی کدنایت | آموزش برنامه نویسی

https://t.me/codenight_ir