Что делать, если внешний API недоступен

Определите, что известно о результате

Тайм-аут означает, что клиент не получил ответ вовремя, но не доказывает, что сервер ничего не сделал. Для операции создания это существенное различие. Прежде чем повторять, проверьте доступный способ узнать состояние по идентификатору. Если такой возможности нет, ограничение нужно учитывать в архитектуре и пользовательском сообщении.

Разделите временную недоступность, ограничение частоты, неверные данные и отсутствие полномочий. Повтор с тем же неверным содержимым редко решает проблему. Не превращайте любую ошибку в бесконечную очередь запросов. Это увеличивает нагрузку и может мешать восстановлению поставщика и вашей системы.

Задайте правила реакции

Ответ HTTP 429 сообщает об ограничении частоты и может содержать Retry-After. Учитывайте предоставленные указания вместе с документацией API. Это не универсальная гарантия безопасного повтора любой операции: создание заказа и чтение справочника имеют разные последствия.

Ограничьте повторы и накопление

Укажите интервалы, предельное число попыток или срок обработки, а также действие после исчерпания. Конкретные значения выбирают под контракт и процесс. Для повторяемого изменения используйте предусмотренную идемпотентность. Если очередь растёт, команда должна видеть возраст задач, а не только факт, что процесс запущен.

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

Учебный пример передачи заказа

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

Для чтения статуса можно использовать другое правило повторов, поскольку действие не создаёт новую доставку. Пользователь видит, что сведения временно уточняются. Пример показывает, почему общий обработчик «повторить всё три раза» не заменяет модель конкретных операций и их побочных эффектов.

Подготовьте разбор неопределённого результата

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

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

Проверьте восстановление

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

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

Что делать с неопределённым результатом внешней операции

Тайм-аут не доказывает, что внешняя система ничего не выполнила. В учебной интеграции CRM создала сделку, но ответ потерялся. Слепой повтор без устойчивого ключа может создать вторую запись.

Прежде чем повторять действие, используйте предусмотренную API проверку состояния по идентификатору. Если такой возможности нет, поместите случай в отдельную очередь разбирательства и сохраните минимальные диагностические данные. Определите, что видит пользователь до выяснения результата. Ошибки чтения и операции с побочным эффектом требуют разных правил повторов. При восстановлении связи проверьте возраст очереди, порядок обработки и фактические связи объектов, а не только успешность следующего HTTP-запроса.