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

Зачем сервисы ограничивают частоту запросов

Лимит защищает общую инфраструктуру: без ограничения один клиент с агрессивным скриптом способен занять ресурсы, которые нужны всем остальным. Это же справедливое распределение мощности — порог на аккаунт гарантирует, что чужая интеграция не съест пропускную способность, оплаченную вами. Упирание в него выглядит конкретно: сервис отвечает кодом 429 и часто прикладывает заголовок с рекомендованной паузой перед повтором. Это принципиально отличается от отказа сервиса — при сбое ошибку получают все клиенты подряд и по разным операциям, а троттлинг адресован именно вашему ключу и именно из-за темпа его запросов. Если в ответе понятный код ограничения, инфраструктура жива и работает штатно — проблема в скорости, с которой вы стучитесь, а не в сервисе.

Равномерный темп вместо всплесков

Многие лимиты считаются за окно времени — секунду или минуту. Если отправить сто запросов одной пачкой и затем простаивать, счётчик окна исчерпывается мгновенно, хотя средняя нагрузка за час может быть скромной. Ограничение реагирует на пик, а не на среднее. Тот же объём работы, распределённый равномерно внутри окна, проходит без единого отказа. Сглаживание темпа — это не про то, чтобы делать меньше запросов, а про то, чтобы не концентрировать их в узкий промежуток.

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

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

Опрос статуса и пауза при отказе

Опрос статуса операции раз в секунду почти всегда избыточен: результат не появляется быстрее оттого, что вы спросили о нём чаще. Реальная операция — доставка SMS, создание порта, обработка платежа — ограничена сетью и внутренней очередью самого сервиса, и опрос чаще этого естественного времени просто сжигает квоту, не приближая ответ. Разумный интервал опроса отталкивается от типичного времени выполнения операции, а не от желания увидеть результат мгновенно.

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

Раздельные лимиты по ключам и мониторинг порога

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

Частые вопросы

Можно ли увеличить лимит для конкретного аккаунта?

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

Почему 429 приходит даже при небольшом темпе запросов?

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

Лимит одинаков для всех методов API?

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

Точные значения лимитов, коды ошибок и заголовки с паузой перед повтором — в документации OTP API.