7 распространённых ошибок при интеграции внешних API, которые стоят нервов и денег
Интеграция внешних API выглядит простой задачей: отправил запрос — получил ответ. Но на практике мелкие ошибки на этапе разработки потом превращаются в ночные инциденты, потерю данных и лишние траты.
За годы работы я видел одни и те же грабли у десятков команд. Собрал 7 самых частых ошибок, которые проще предотвратить, чем потом исправлять последствия.
Список ошибок
- Отсутствие идемпотентности запросов.При повторной отправке одного и того же запроса данные дублируются на стороне провайдера. Особенно опасно для платёжных и создающих операций. Правильный подход — использовать уникальный идемпотентный ключ для каждой операции.
- Хардкод ключей и настроек в коде.Чтобы поменять ключ или адрес сервиса, приходится выпускать новую версию сервиса. Все секреты и конфигурации должны храниться в переменных окружения или отдельном сервисе конфигураций.
- Игнорирование ошибки 429 и мгновенный повтор.Когда провайдер выдаёт лимит запросов, многие системы сразу начинают повторять запрос снова и снова. В результате сервис блокирует вас ещё сильнее. Об этом я подробно писал в прошлой статье про лимиты и retry.
- Одинаковый retry для всех типов ошибок.Многие настраивают повторные попытки на любую ошибку подряд. Но ошибки авторизации или валидации никогда не исправятся от повторения — вы просто зря нагрузите систему.
- Отсутствие таймаутов на запросы.Если внешний сервис завис и не отвечает, запрос повисает. При большом количестве таких запросов они постепенно съедают все ресурсы вашего сервиса и кладут его целиком. Любой вызов во внешнюю систему должен иметь явный таймаут.
- Тестирование только успешного сценария.Разработчики проверяют, что всё работает при нормальном ответе, но не проверяют сбои, лимиты и медленные ответы. В результате все проблемы вылезают только на продакшене.
- Нет единого мониторинга ошибок.Когда у вас десятки разных API, сложно понять, где начались проблемы. Без единого дашборда по проценту ошибок и задержкам вы узнаёте о сбоях последними от пользователей.
Большинство проблем с внешними API возникают не из-за сбоев провайдера, а из-за плохой подготовки со стороны нашей системы.
Итоги
Большинство этих ошибок легко исправляются на этапе проектирования. Достаточно один раз выстроить общий подход к внешним вызовам — и потом не тратить часы на разбор инцидентов.
Если у вас много внешних интеграций, самый выгодный вложение — один раз сделать стандартный слой-обёртку с едиными логами, лимитами, retry и мониторингом. Это окупится за пару месяцев.
Если нужен готовый чек-лист для аудита внешних интеграций и шаблон стандартного слоя-обёртки — я добавил эти материалы в телеграм-канал, ссылка в профиле.
В комментариях напишите, какая из этих ошибок была у вас. Или есть свой самый болезненный кейс при интеграции внешних API?