API отвечает 429 после запуска второго обработчика: где должен жить общий лимит

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

У кого именно закончились запросы

HTTP 429 сообщает об ограничении частоты запросов. RFC 6585 допускает заголовок Retry-After, но не задаёт единого способа подсчёта: сервер может учитывать пользователя, ресурс или другую область. Поэтому одного кода недостаточно, чтобы выбрать алгоритм интеграции.

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

Разрешение берут до обращения к API

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

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

Не смешивайте частоту и одновременность

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

Повтор тоже тратит бюджет

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

Если получен применимый Retry-After, обработайте его по правилам протокола и конкретного API. Заголовок может задавать задержку или дату; некорректное значение требует определённой резервной политики. Разброс задержек помогает разнести одновременные повторы, но не создаёт дополнительной квоты. Общая пауза относится к установленной области ограничения, а не обязательно ко всему приложению.

Посмотрите на расписание, а не на обещанную скорость

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

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

Как принять исправление

1. На тестовой среде запустить несколько экземпляров с одним бюджетом.
2. Проверить границу окна, общую паузу и одновременное получение последнего разрешения.
3. Убедиться, что повторы учитываются наравне с первыми попытками.
4. Показать в мониторинге область квоты, время ожидания разрешения и причину остановки.

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