Что нужно знать джуну про EDA

Cобытийно-ориентированная архитектура (event-driven architecture, EDA) — архитектура, которая позволяет в режиме реального времени обнаруживать, обрабатывать, управлять и реагировать на события.

Нужна в системах, где возникает много независимых событий, которые не зависимы от времени и могут появиться в рандомное время. Например, заказы на маркетплейсах — не зависят от времени, их много, они разнообразные. Событием может быть "Заказ создан", "Оплата подтверждена", "Товар отправлен". Эти события запускают другие процессы: списание средств, уведомление клиента, обновление инвентаря, повторная доставка

Событие — любое изменение состояния некой сущности или возникновение новой.

📚 Компоненты EDA
— Производители генерируют события и отправляют их брокеру.
— Брокер фильтрует и направляет события соответствующим потребителям.
— Потребители подписываются на нужные им каналы событий, прослушивают их и обрабатывают в соответствии с бизнес-логикой.

👋 В событийной архитектуре производители и получатели отделены друг от друга. Производитель не знает, какие получатели принимают события, а пользователи не знают, какие производители их генерируют.

👯 Модели доставки событий
— В pub/sub модели инфраструктура обмена сообщениями отслеживает подписки и отправляет события каждому подписчику.
— При потоковой передаче события записываются в лог событий, а получатели могут читать их из любой части потока. Это помогает легко восстановить состояние системы после сбоя, в отличие от RESTful микросервисов.
Для реализации обеих моделей можно использовать RabbitMQ и Kafka

✅ Преимущества EDA
• Слабая связность и гибкость
Благодаря слабой связности упрощается подключение других микросервисов при изменении архитектуры, что дает высокую скорость масштабирования. Использование событийной архитектуры для уменьшения связанности — популярная идея при проектировании, однако не стоит выстраивать сложные цепочки по передаче событий из сервиса в сервис. Координация workflow сервисов с помощью команд (оркестрация), а не событий, позволяет еще больше уменьшить связанность.
• Отказоустойчивость
Один из недостатков REST архитектуры — наличие единой точки отказа. Если один сервис выходит из строя, весь workflow нарушается. Здесь событийная архитектура наиболее ярко проявляет свое преимущество. Если один из серверов выйдет из строя, другие будут перехватывать сообщения. Более того, сообщения сохраняются, когда потребитель отключается, и отправляются, как только потребитель снова начинает прослушивать сообщения.

⛔️ Сложности при работе с EDA
• Упорядочивание событий
Правильный порядок событий может быть необходим в некоторых сценариях, таких как финансовые транзакции, и требует тщательной разработки и реализации, что может оказаться сложной задачей.
• Откат транзакций
Если в одном из сервисов произошло исключение, то оно должно произойти со всем потоком событий. Вдобавок необходимо поддерживать целостность данных и обеспечивать корректное обновление всех соответствующих систем в ответ на события и исключения.
• Отладка и исправление неисправностей
События могут вызывать ряд реакций сразу в нескольких компонентах, что затрудняет отслеживание потока и выявление первопричины проблем

Модели EDA-архитектуры бывают разные. Если интересно погрузиться подробнее, почитать можно тут.