Интеграция считается работающей не тогда, когда сообщение дошло. А тогда, когда бизнес-процесс получил нужный контекст и продолжился корректно

Две системы легко связать напрямую.

Десять систем создают уже десятки потенциальных зависимостей.

Каждое изменение контракта начинает затрагивать несколько связей. Ошибки трудно трассировать. Логика преобразования дублируется.

AMPE не вводит ESB, iPaaS или event bus «потому что так правильно». Мы смотрим, когда сложность связей действительно требует отдельного интеграционного слоя.

Синхронный API нужен, когда ответ требуется сейчас.

Событие — когда факт изменения должен стать доступен нескольким потребителям без жёсткой связи.

Batch — когда допустима задержка и важнее эффективность обработки объёма.

CDC — когда нужно передавать изменения данных близко к источнику.

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

Когда данные вручную переносятся между системами.

Когда один и тот же объект имеет разные статусы.

Когда интеграции регулярно ломаются после изменений.

Когда нет общего понимания, какая система является источником истины.

Когда ошибки обмена обнаруживаются только по жалобе пользователя.

Когда несколько потребителей зависят от одного события.

Когда бизнес-процесс проходит через границы приложений и теряет контекст.

Сеть нестабильна. Клиент повторил запрос. Consumer перезапустился. Сообщение доставлено снова.

Технически это нормальные ситуации.

Но повторно создать платёж, заказ или отгрузку — уже бизнес-ошибка.

Поэтому AMPE рассматривает идемпотентность как часть контракта обработки, а не редкую защиту.

Если downstream недоступен, бесконечные повторные запросы усиливают нагрузку.

Нужны: timeout; backoff; лимит попыток; DLQ или другой маршрут исключения; наблюдаемость.

Интеграция должна уметь корректно пережить отказ другой системы.

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

Но для двух простых систем он может добавить лишний слой.

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

Бизнес-событие получает идентификатор и контекст.

Контракт определяет данные и семантику. Транспорт обеспечивает доставку. Обработчик применяет правила. Статус обработки наблюдается. Ошибка получает управляемый маршрут. Результат возвращается в процесс.

Так интеграция становится частью исполнения, а не скрытым техническим мостом.

Снижается ручной перенос данных.

Интеграции легче изменять и наблюдать.

Повторная обработка становится безопаснее.

Ошибки не теряются между системами.

Источники данных и ответственность становятся понятнее.

И главное — сквозной процесс сохраняет контекст даже при сложном IT-ландшафте.