Как защитить бизнес-процесс от отказа внешнего API

Внешний API становится частью надёжности вашего сервиса, даже если вы не управляете его инфраструктурой. Без изоляции медленный ответ партнёра занимает рабочие потоки, увеличивает очередь запросов и может остановить функцию, которая напрямую с этим партнёром не связана.

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

Начните с бизнес-результата

Для каждой внешней операции ответьте на четыре вопроса:

1. нужен ли ответ прямо сейчас;
2. можно ли завершить работу позже;
3. допустим ли временный результат из кэша;
4. что увидит пользователь при недоступности.

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

Зафиксируйте владельца зависимости, допустимое время ответа, срок хранения незавершённой операции и способ ручного восстановления.

Тайм-аут должен быть частью общего бюджета

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

• приём и проверку запроса;
• внутреннюю бизнес-логику;
• сетевое соединение;
• внешний API;
• запись результата;
• формирование ответа.

Устанавливайте отдельные тайм-ауты на соединение и чтение ответа. Значения должны следовать из измерений, а не из библиотечного значения по умолчанию. Слишком длинный тайм-аут удерживает ресурсы; слишком короткий создаёт ложные отказы и лишние повторы.

Ограниченные повторы вместо бесконечного retry

Повтор полезен при кратком сетевом сбое, но опасен при перегрузке внешнего сервиса. Если все клиенты одновременно повторяют запросы, нагрузка растёт именно в момент аварии.

Безопасный retry обычно включает:

• ограниченное число попыток;
• экспоненциальную задержку;
• случайный разброс времени;
• проверку типа ошибки;
• общий дедлайн операции;
• идемпотентность изменяющего запроса.

Не повторяйте автоматически запрос, если неизвестно, выполнил ли партнёр операцию. Используйте idempotency key или отдельную проверку статуса. Общие правила идемпотентности разобраны в материале об интеграционной API-архитектуре.

Circuit breaker ограничивает каскадный отказ

Circuit breaker временно прекращает вызовы зависимости, когда доля ошибок или задержка превышают порог. Это освобождает ресурсы и даёт внешнему сервису восстановиться.

У механизма три состояния:

• closed — вызовы выполняются;
• open — новые вызовы быстро отклоняются;
• half-open — ограниченное число проверок определяет, восстановился ли сервис.

Порог нельзя выбирать только по числу ошибок: на малом трафике единичный сбой не должен открывать контур, а при большом трафике абсолютное число быстро становится бессмысленным. Нужны окно наблюдения, минимальный объём запросов и отдельные правила для ошибок и высокой задержки.

Очередь отделяет приём от выполнения

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

Для очереди предусмотрите:

• максимальное число повторов;
• dead-letter queue;
• срок жизни сообщения;
• дедупликацию;
• ограничение скорости обработки;
• ручной повтор после исправления;
• защиту чувствительных данных.

Очередь не решает проблему автоматически. Без владельца и алертов она лишь скрывает растущий долг.

Fallback должен быть честным

Резервное поведение зависит от смысла операции:

Сценарий	Возможный fallback
Справочная информация	Кэш с указанием времени обновления
Необязательная рекомендация	Работа без рекомендации
Отправка уведомления	Очередь и другой разрешённый канал
Проверка критичного условия	Остановка с понятным статусом
Получение курса или тарифа	Последнее значение только при допустимом сроке

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

Изолируйте зависимости

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

Так проще:

• заменить поставщика;
• включить тестовую заглушку;
• ограничить скорость;
• централизованно вращать ключи;
• маскировать логи;
• измерять ошибки конкретного партнёра.

Что измерять

Среднее время ответа не показывает редкие, но болезненные задержки. Контролируйте:

• p50, p95 и p99 задержки;
• долю тайм-аутов;
• ошибки по типу и операции;
• число повторов;
• время circuit breaker в открытом состоянии;
• возраст очереди;
• размер DLQ;
• процент операций, завершённых через fallback;
• время от приёма до бизнес-результата.

Свяжите технические показатели с SLO процесса. Как это сделать, описано в статье о SLI, SLO и бюджете ошибок.

Испытайте отказ до промышленного запуска

В тестовой среде проверьте:

1. медленный ответ;
2. обрыв соединения;
3. ответы 429 и 5xx;
4. некорректную схему ответа;
5. успешное выполнение при потерянном ответе;
6. восстановление после открытия circuit breaker;
7. переполнение очереди;
8. отзыв или истечение ключа доступа.

Результатом теста должен быть не только успешный retry, но и понятное поведение пользователя, алерт для дежурной команды и инструкция восстановления.

Как можем помочь

«Лоджик Телеком» может помочь построить карту внешних зависимостей, определить бюджеты времени и спроектировать адаптеры, очереди и наблюдаемость. Начните с процесса, где отказ партнёра сегодня создаёт ручную работу или останавливает обслуживание клиентов.