Во многих системах один процесс выглядит как цепочка прямых вызовов: заказ создан — вызвать оплату, затем склад, затем уведомления, затем аналитику.
Пока участников мало, это понятно. Но каждый новый потребитель добавляет зависимость: система заказов должна знать, кого ещё вызвать и что делать, если кто-то не ответил.
Event-Driven Architecture предлагает другую модель: система сообщает, что событие произошло, а заинтересованные системы сами решают, как на него реагировать.
Какую проблему мы решаем
Главная проблема — слишком тесная связанность систем и процессов.
Если после создания заказа нужно запустить пять разных действий, сервис заказов не обязательно должен координировать все пять. Он может опубликовать событие «Заказ создан», а склад, CRM, уведомления и аналитика обработают его независимо.
Так новые реакции можно добавлять без изменения источника события.
Что получает бизнес
Главная бизнес-выгода — дешевле подключать новые процессы и каналы вокруг уже существующих событий.
Появилась новая программа лояльности? Она может подписаться на покупку. Нужна новая аналитика? Ей не обязательно менять систему заказов. Появился новый канал уведомлений? Его можно подключить к тем же событиям.
Это уменьшает стоимость интеграций и снижает риск, что изменение одного бизнес-процесса потребует переписывать несколько соседних систем.
Есть и эффект устойчивости: временная недоступность второстепенного потребителя не обязана останавливать основную операцию. Заказ может быть принят, даже если аналитика обработает событие позже.
Но бизнес должен быть готов к тому, что часть процессов становится не мгновенной, а согласуется со временем.
Что получает команда
Команды получают более слабую связанность. Источник события знает факт, который произошёл, но не обязан знать всех потребителей.
Новые системы можно подключать без изменения уже работающего кода источника.
При этом появляются новые инженерные задачи: повторная доставка, порядок событий, идемпотентность, версии схем событий и наблюдаемость сквозного процесса.
Что получает клиент
Клиент может получить более устойчивый продукт: сбой второстепенной системы не обязательно блокирует основное действие.
Также компании проще добавлять новые реакции на действия клиента — уведомления, программы лояльности, рекомендации, интеграции.
Но клиент может столкнуться с временной несогласованностью. Заказ уже создан, а бонусы или статус в другой системе обновились через несколько секунд.
Чем мы за это платим
Цена событийной архитектуры — сложнее понять, что происходит прямо сейчас.
В синхронной цепочке можно пройти по вызовам. В событийной системе один факт запускает несколько независимых реакций, часть из которых может произойти позже или повториться.
Нужны мониторинг событий, понятные схемы, правила повторной обработки и инструменты для расследования сквозных бизнес-процессов.
Есть и архитектурный риск: если любое изменение превратить в событие без чёткой модели, вместо слабой связанности получится поток сообщений, смысл которых никто до конца не понимает.
Когда Event-Driven Architecture не нужна
Если процесс простой, требует немедленного ответа и состоит из двух тесно связанных шагов, прямой вызов часто понятнее и дешевле.
События особенно полезны там, где на один факт реагируют несколько независимых систем или новые потребители регулярно появляются со временем.
Что стоит спросить перед решением
- Нужно ли источнику события действительно знать всех потребителей?
- Может ли часть реакции произойти позже?
- Что будет, если одно событие обработается дважды?
- Как мы увидим состояние сквозного бизнес-процесса?
- Как будем менять формат событий без поломки потребителей?
В итоге
Event-Driven Architecture позволяет бизнес-процессам расти вокруг событий без постоянного усложнения системы-источника.
Это хороший способ купить гибкость интеграций и устойчивость — если компания готова заплатить за асинхронность, наблюдаемость и более сложную модель данных во времени.