Event-Driven در نرم افزار

Event-Driven Architecture؛ ستون فقرات سیستم‌های توزیع‌شده مدرن

سلام دوستان؛ در این مقاله موضوع Event-Driven Architecture رو بررسی میکنیم. احتمالاً این مقاله برای افراد غیرفنی زیاد جالب نباشه و مخاطب خاصش، معمار ها و تحلیل گر ها، توسعه دهنده و علاقه مندان به برنامه نویسی خواهد بود.

با رشد سیستم‌ها، افزایش نیاز به مقیاس‌پذیری و حرکت به سمت معماری‌های توزیع‌شده، الگوهای سنتی request/response و coupling مستقیم بین سرویس‌ها به‌تدریج به گلوگاه تبدیل می‌شوند. در چنین فضایی، Event-Driven Architecture (EDA) نه به‌عنوان یک انتخاب فانتزی، بلکه به‌عنوان یک ضرورت معماری مطرح می‌شود. EDA مدلی است که در آن سیستم‌ها به‌جای فراخوانی مستقیم یکدیگر، با انتشار و مصرف Eventها با هم تعامل می‌کنند.

در این مقاله، Event-Driven Architecture را به‌صورت کاملاً فنی و عمیق بررسی می‌کنیم؛ از مدل ذهنی و مفاهیم پایه گرفته تا پیاده‌سازی واقعی با ابزارهای رایج. هدف این است که اگر بخواهیم یک سیستم واقعی مبتنی بر EDA طراحی و پیاده‌سازی کنیم، بتوانیم از مفاهیم پایه ای که در اینجا خواهم گفت، استفاده کنیم.

مسئله اصلی؛ چرا معماری‌های سنتی مقیاس‌پذیر نیستند؟

در معماری‌های synchronous، هر سرویس برای انجام کار خود به پاسخ سرویس‌های دیگر وابسته است. این وابستگی زنجیره‌ای باعث افزایش latency، شکنندگی سیستم و propagation خطا می‌شود. اگر یکی از سرویس‌ها down شود یا کند پاسخ دهد، کل زنجیره تحت تأثیر قرار می‌گیرد.

علاوه بر این، coupling زمانی (temporal coupling) مشکل بزرگی است. سرویس‌ها باید هم‌زمان در دسترس باشند تا یک سناریوی بیزینسی اجرا شود. Event-Driven Architecture دقیقاً برای شکستن این وابستگی طراحی شده است.

Event-Driven Architecture چیست؟

ابتدا میخوام یک تعریف دقیق داشته باشیم. Event-Driven Architecture سبکی از معماری است که در آن Event به‌ عنوان واحد اصلی ارتباط بین اجزای سیستم استفاده می‌شود. Event بیانگر این است که «چیزی در سیستم اتفاق افتاده است»، نه اینکه «چه کاری باید انجام شود».

در EDA، Producer یک Event را منتشر می‌کند، بدون اینکه بداند چه کسی یا چند Consumer آن را دریافت خواهند کرد. Consumerها هم بر اساس Eventهایی که دریافت می‌کنند، واکنش نشان می‌دهند. این مدل باعث loose coupling، scalability بالا و انعطاف‌پذیری در توسعه می‌شود.

Event چیست و چه چیزی Event نیست؟

با توجه به اینکه باید بدونیم Event دقیقا به چه معنایی هست، میخوام جمله دقیقی رو بیان کنم. Event یک واقعیت immutable است که در گذشته رخ داده و قابل تغییر نیست. نام‌گذاری Event بسیار مهم است و معمولاً باید به صورت past tense باشد، مثل OrderCreated یا PaymentCompleted. یعنی جریانی که در گذشته رخ داده است.

در مقابل، Command یا Request بیانگر نیت انجام یک کار است. اشتباه رایج این است که Commandها را به‌عنوان Event منتشر کنیم. این کار مرز مسئولیت‌ها را مخدوش می‌کند و coupling منطقی ایجاد می‌کند. معمار ها، تحلیل گر ها و توسعه دهنده ها باید دقت کافی رو داشته باشند.

اجزای اصلی Event-Driven Architecture

EDA معمولاً از چند جزء کلیدی تشکیل می‌شود. Producer که Event را تولید می‌کند، Broker یا Message Bus که Event را منتقل می‌کند و Consumerهایی که Event را مصرف می‌کنند. هر کدام از این اجزا مسئولیت مشخص و محدودی دارند.

Broker نقش بسیار مهمی در تضمین ordering، delivery و durability Eventها دارد. انتخاب Broker مناسب تأثیر مستقیمی بر قابلیت اطمینان سیستم دارد.

Message Broker؛ قلب تپنده EDA

پیاده‌سازی EDA بدون Message Broker عملاً غیرممکن است. ابزارهایی مثل Apache Kafka، RabbitMQ و Pulsar رایج‌ترین گزینه‌ها هستند. Kafka معمولاً برای throughput بالا و event streamهای بزرگ استفاده می‌شود، در حالی که RabbitMQ بیشتر برای messaging کلاسیک و routing پیچیده کاربرد دارد.

در معماری Event-Driven، باید تفاوت بین queue و topic را به‌خوبی درک کرد. Queue معمولاً برای load balancing استفاده می‌شود، اما topic امکان fan-out و مصرف چندگانه Event را فراهم می‌کند. در مورد این بخش بیشتر صحبت خواهیم کرد.

Event Schema و Contract

Eventها contract بین سرویس‌ها هستند. تغییر نادرست در schema Event می‌تواند چندین سرویس را هم‌زمان بشکند. به همین دلیل، versioning و backward compatibility در Eventها حیاتی است.

استفاده از schema registry (مثلاً در Kafka) و فرمت‌هایی مثل Avro یا Protobuf به‌شدت توصیه می‌شود. Event باید self-descriptive باشد و حداقل اطلاعات لازم برای Consumer را فراهم کند.احتمالاً برخی دوستان ندونن بحث Avro چی هست پس همینجا یک اشاره کوچیکی داشته باشم بهش که Avro یک فرمت serialization باینری هست و مزیتش این است که schema جدا از payload ذخیره می‌شود و فقط ID آن داخل پیام قرار می‌گیرد. این کار باعث کاهش حجم پیام می‌شود. موضوع Protobuf هم که احتمالاً با gRPC کار کرده باشند، آشنا هستند دیگه. مال گوگل هست و ساختار strongly typed داره. معمار های با تجربه مون میدونن که در سیستم های high-throughput ، معمولا یا Avro یا protobuf استفاده میشه.

بزارید این رو هم بگم بریم سراغ موضوعات بعدی. اگر نمیدونید schema registry چی هست در کافکا، Schema Registry یک سرویس مرکزی است که:

• ساختار (Schema) هر Event را ذخیره می‌کند

• Versionهای مختلف آن را نگه می‌دارد

• قبل از publish شدن Event، اعتبار آن را بررسی می‌کند (مهم هست خیلی)

• سازگاری (compatibility) نسخه جدید با نسخه‌های قبلی را enforce می‌کند. حالا دیگه نمیخوام خیلی وارد مباحث Backward، Forward بشم. Backward میگه نسخه جدید باید بتواند داده‌های نسخه قبلی را بخواند اون یکی هم برعکش رو میگه.

Delivery Semantics؛ از At-Most-Once تا Exactly-Once

بریم سراغ سمانتیک های تحویل و ببینیم که موضوع چی هست. در EDA باید صراحتاً مشخص شود که semantics تحویل Event چیست. At-most-once ساده ولی غیرقابل‌اعتماد است. At-least-once رایج‌ترین انتخاب است، اما نیازمند idempotent consumerهاست. Exactly-once پیچیده و معمولاً پرهزینه است و فقط در سناریوهای خاص ارزش دارد.

طراحی Consumerها باید بر اساس at-least-once انجام شود و duplicate Eventها به‌عنوان واقعیت سیستم پذیرفته شوند.

Eventual Consistency؛ واقعیت اجتناب‌ناپذیر

EDA معمولاً به consistency آنی منجر نمی‌شود. بین انتشار Event و واکنش Consumerها تأخیر وجود دارد. این موضوع باید از ابتدا در طراحی بیزینسی پذیرفته شود. Eventual Consistency trade-off آگاهانه‌ای برای دستیابی به availability و scalability است که معمار ما باید حواسش باشه.

نمایش وضعیت موقت، handling stateهای intermediate و طراحی UX مناسب بخشی از پیامدهای این انتخاب معماری هستند.

طراحی Consumerها؛ Stateless یا Stateful؟

Consumerها می‌توانند stateless یا stateful باشند. Consumerهای stateless ساده‌تر و مقیاس‌پذیرترند، اما در برخی سناریوها نیاز به نگه‌داشت state وجود دارد. در این حالت، مدیریت offset و persistence state اهمیت زیادی پیدا می‌کند. همچنین error handling و retry باید با دقت طراحی شوند تا از infinite loop جلوگیری شود.

EDA و CQRS

Event-Driven Architecture به‌صورت طبیعی با CQRS هم‌راستا است. Commandها باعث تغییر state می‌شوند و Eventها نتیجه این تغییرات را منتشر می‌کنند. Read Modelها معمولاً با مصرف Eventها ساخته و به‌روزرسانی می‌شوند.

این ترکیب امکان scale مستقل read و write را فراهم می‌کند و برای سیستم‌های با read-heavy workload بسیار مناسب است.

مثال واقعی؛ سیستم فروش آنلاین Event-Driven

در یک سیستم فروش آنلاین، Order Service بعد از ایجاد سفارش، OrderCreatedEvent منتشر می‌کند. Payment Service با دریافت این Event فرآیند پرداخت را آغاز می‌کند. Inventory Service موجودی را به‌روزرسانی می‌کند و Notification Service ایمیل یا پیام ارسال می‌کند.

Order Service هیچ اطلاعی از Consumerها ندارد و همین موضوع باعث می‌شود اضافه یا حذف سرویس‌های جدید بدون تغییر در Producer انجام شود.

Observability در Event-Driven Architecture

Debug کردن EDA سخت‌تر از معماری synchronous است. Trace کردن یک Event در چند سرویس نیازمند logging ساختاریافته، correlation id و ابزارهای observability مثل OpenTelemetry است.

بدون observability مناسب، EDA به‌سرعت به یک black box تبدیل می‌شود و واقعا نمیشه دقیق فهمید چه اتفاقاتی داره در داخل سیستم رخ میده. همیشه به معمار ها و تحلیل گر ها میگم که موضوع observability باید جدی در نظر گرفته بشه منتها کو گوش شنوا 😄

چالش‌ها و Anti-Pattern ها

استفاده افراطی از Event، انتشار Eventهای بسیار granular یا برعکس بیش‌ازحد coarse، و تبدیل Event Broker به دیتابیس از anti-pattern های رایج هستند. این موضوع رو هم باید دقت داشته باشیم روش.

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

جمع‌بندی

Event-Driven Architecture یکی از پایه‌ای‌ترین الگوهای معماری برای ساخت سیستم‌های مدرن، scalable و resilient است. این معماری با حذف coupling مستقیم، امکان رشد مستقل سرویس‌ها و واکنش‌پذیری بالا را فراهم می‌کند. حالا خیلی از عزیزان میان و این موضوع رو با SAGA هم ترکیب میکنن و یه سیستم ترتمیزی میاد بیرون ازش. اگر در مورد SAGA اطلاعات بیشتری نیاز دارید، میتونید این مقاله رو مطالعه کنید. یک Cheat Sheet کلی هم در زیر قرار میدم برای پترن های رایج مثل outbox و event sourcing و aggregation.

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