Событийная архитектура: когда бизнес-событие лучше прямого вызова

Когда использовать события, как назвать бизнес-факт, отделить производителя от потребителей, версионировать схему и учитывать порядок.

Событие сообщает о свершившемся факте, позволяя нескольким потребителям реагировать независимо и не заставляя исходную систему знать каждый сценарий.

Назовите факт

Формулируйте завершенное бизнес-действие с идентификатором, временем и нужным контекстом, не превращая событие в скрытую удаленную команду. Смысл документируйте.

Примите неопределенность

Доставка может повториться или изменить порядок, поэтому потребитель обязан быть идемпотентным и проверять версию объекта. Идеальный порядок не обещайте.

Не усложняйте без причины

Для простого синхронного запроса один API понятнее брокера, схем, повторов и распределенной диагностики. Выбор обоснуйте нагрузкой.

До промышленного внедрения обязательно определите владельца схемы, срок хранения, допустимый объем, правила работы с персональными данными, контроль доступа и безопасный способ воспроизведения событий после исправления ошибочного потребителя без повторного бизнес-действия.

Доставку событий дополняет сравнение вебхуков и polling. Очереди требуют отдельной политики ошибок.