همفکران فناوری شریف
۱مقدمه
در معماری سنتی، هر سرویس برای انجام کار خود، سرویس دیگر را به‌طور مستقیم فراخوانی می‌کند و منتظر پاسخ می‌ماند. اگر یکی از سرویس‌ها کند یا از دسترس خارج شود، این زنجیرهٔ وابستگی می‌تواند کل سامانه را متوقف کند. در سامانه‌های پرداخت که در ساعات اوج با هجوم ناگهانی تراکنش روبه‌رو می‌شوند، این شکنندگی هزینهٔ سنگینی دارد.
۲بررسی موضوع
در معماری رویدادمحور (Event-Driven Architecture)، سرویس‌ها به‌جای فراخوانی مستقیم، «رویداد» منتشر می‌کنند؛ مانند «پرداخت انجام شد» یا «حساب شارژ شد». سرویس‌های دیگر که به آن رویداد علاقه دارند، آن را دریافت و پردازش می‌کنند. منتشرکننده نیازی ندارد بداند چه کسی و چه زمانی رویداد را پردازش می‌کند؛ این جداسازی، پایه‌ای برای مقیاس‌پذیری و تاب‌آوری است.
واسط پیام (Message Broker) زیرساختی است که رویدادها را دریافت، ذخیره و تحویل می‌دهد. ابزارهایی مانند Apache Kafka برای جریان‌های پرحجم و قابل بازپخش، و RabbitMQ برای صف‌های کاری با الگوهای مسیریابی متنوع، از گزینه‌های رایج‌اند. ویژگی مهم این ابزارها، نگه‌داشتن پیام تا زمان پردازش موفق است؛ بنابراین اگر سرویس مصرف‌کننده موقتاً از کار بیفتد، هیچ تراکنشی گم نمی‌شود.
چالش اساسی در سامانه‌های مالی، تضمین «دقیقاً یک‌بار» پردازش است. شبکه ممکن است یک پیام را دوبار تحویل دهد و پرداخت تکراری، فاجعه است. راهکار رایج، طراحی «خودتوان» (Idempotent) است: هر رویداد شناسهٔ یکتا دارد و سرویس مصرف‌کننده، پیش از اجرا بررسی می‌کند که آن شناسه قبلاً پردازش نشده باشد.
الگوی «صندوق خروجی» (Outbox Pattern) مشکل دیگری را حل می‌کند: اطمینان از اینکه تغییر پایگاه داده و انتشار رویداد، هر دو با هم انجام شوند یا هیچ‌کدام. در این الگو، رویداد ابتدا در همان تراکنش پایگاه داده در جدولی جداگانه ثبت و سپس توسط فرایندی مستقل منتشر می‌شود. این روش از ناهماهنگی میان وضعیت حساب و پیام‌های منتشرشده جلوگیری می‌کند.
۳جمع‌بندی
معماری رویدادمحور پیچیدگی‌های خود را نیز دارد: دشواری ردیابی یک تراکنش در میان چندین سرویس، «سازگاری نهایی» به‌جای سازگاری لحظه‌ای، و نیاز به پایش دقیق صف‌ها. بنابراین این معماری برای بخش‌هایی مناسب است که حجم بالا و نیاز به جداسازی دارند، و نه لزوماً برای همهٔ اجزای یک سامانه.
منابع
