Event-driven нужен не тогда, когда «у нас много систем». Он нужен тогда, когда факт события должен стать доступен нескольким участникам без жёсткой связи между ними

`OrderCreated` — событие.

`CreateInvoice` — команда.

Разница важна.

Событие сообщает о том, что уже произошло.

Команда просит конкретного участника что-то сделать.

Если смешать эти понятия, event bus быстро превращается в скрытый RPC.

CRM опубликовала факт создания заказа.

ERP может его обработать.

BI — учесть в аналитике.

Notification service — отправить сообщение.

Fraud service — проверить риск.

Источник не должен менять код каждый раз, когда появляется новый потребитель.

В этом и состоит одна из ключевых причин event-driven.

Если системы реагируют независимо, их состояния обновляются не одновременно.

На короткое время одна система уже знает новое, а другая ещё нет.

AMPE определяет:

какое рассогласование допустимо;

сколько оно может длиться;

что видит пользователь;

как обнаружить застрявшую обработку.

Слишком маленький event заставляет consumer сразу идти обратно в producer за контекстом.

Слишком большой — создаёт лишнюю связанность и дублирование.

AMPE выбирает payload по тому, какой минимум данных нужен потребителю для осмысленной реакции.

Для некоторых потоков порядок критичен.

Нельзя обработать `OrderCancelled` раньше `OrderCreated`.

Для других — отдельные события независимы.

Глобальный ordering дорого масштабируется.

Поэтому AMPE сохраняет порядок там, где он важен по business key или partition, а не «на всякий случай» для всего мира.

At-least-once delivery означает, что consumer должен уметь безопасно увидеть одно событие дважды.

Это нормальное свойство многих брокеров.

AMPE проектирует:

event ID;

business key;

deduplication;

idempotent processing;

state check.

Так повторная доставка не становится повторной бизнес-операцией.

Добавятся поля.

Старые потребители будут обновляться позже.

Поэтому важны:

backward compatibility;

schema registry или другой контроль;

версионирование;

deprecation.

Событие живёт дольше конкретного релиза producer.

Broker доставляет сообщения.

Event store может хранить последовательность событий как источник состояния.

Event sourcing — отдельная архитектурная модель, а не обязательная часть event-driven.

AMPE не вводит event sourcing только потому, что в системе уже есть Kafka или другой брокер.

Оплата пришла.

ERP фиксирует финансовый факт.

CRM снимает блокировку.

WMS получает разрешение на отгрузку.

BI обновляет показатель.

Notification service сообщает клиенту.

Один факт запускает несколько независимых реакций без центрального orchestrator на каждый шаг.

Если пользователю нужен немедленный ответ, обычный API часто проще.

Если операция жёстко последовательна и имеет одного исполнителя, command pattern может быть яснее.

Если система маленькая, брокер может добавить больше сложности, чем пользы.

AMPE использует event-driven там, где преимущества развязки действительно окупают новые требования к эксплуатации.

Бизнес-факт возникает у владельца.

Producer публикует событие.

Broker обеспечивает доставку.

Consumers обрабатывают его независимо.

Ошибки получают retry или отдельный маршрут.

Observability связывает всю цепочку по correlation ID.

Так система реагирует на изменения без жёсткой сети прямых вызовов.

Новые consumers подключаются с меньшим влиянием на producer.

Системы меньше зависят от одновременной доступности друг друга.

Сквозные реакции становятся естественнее.

Масштабирование обработчиков становится независимым.

Изменения легче локализовать.

И главное — событие становится общей точкой факта, вокруг которой разные системы строят собственную работу.