MTB ESB Documentation

Reliability и ошибки

Timeout, retry, DLQ, callback, recovery и единая классификация ошибок.

Reliability и ошибки

Надёжность проектируется для всего маршрута. Без явных timeout и retry один недоступный backend способен создать накопление сообщений и каскадный отказ.

Timeout budget

End-to-end timeout распределяется между Gateway, Router/transport, adapter и target system. Внутренний timeout должен оставлять время на формирование контролируемого ответа.

Retry rules

Повтор допускается только для transient errors и безопасной операции. Используйте ограниченное число попыток, exponential backoff и jitter.

Не повторяйте автоматически:

  • validation и authorization errors;
  • business rejection;
  • write-операцию без idempotency guarantee;
  • запрос после неизвестного результата, пока не определён reconciliation path.

DLQ / DLT

После исчерпания retry сообщение перемещается в контролируемый dead-letter flow. Для него определяются alert, owner, retention, диагностика, replay approval и защита от повторного poison message.

Replay — это production change

Ручное повторное воспроизведение может повторить бизнес-операцию. Перед replay проверяются idempotency, фактическое состояние target system и разрешение владельца.

Error categories

КатегорияПримерПовтор
ValidationНеверная schemaНет
Authentication/authorization401/403После исправления доступа
Rate limiting429После Retry-After/backoff
Business rejectionНедопустимое состояниеОбычно нет
Transient technicalTimeout, временная недоступностьОграниченный retry
Permanent technicalНеверная конфигурация/routeНет, требуется исправление

Async callback

Callback delivery имеет отдельные timeout, retry и DLT. Consumer проверяет signature, использует allowlist и обрабатывает дубликаты идемпотентно.

Observability signals

  • latency по сегментам;
  • error rate по category;
  • retry volume;
  • consumer lag;
  • DLQ depth;
  • callback success rate;
  • stuck orchestration executions.

On this page