Как работать с лимитами внешнего API

Узнайте, к чему относится лимит

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

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

Посчитайте поток операций

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

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

Карта обработки ответов

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

Что означает 429

MDN описывает 429 Too Many Requests как превышение частоты запросов. Ответ может содержать Retry-After с указанием ожидания. Если такой заголовок предусмотрен и получен, обработчик должен корректно разобрать его формат и не продолжать немедленные повторы.

При отсутствии явного времени применяют согласованную задержку с увеличением интервала и распределением повторов. Конкретные пределы зависят от контракта и допустимого времени выполнения. Бесконечный повтор каждую секунду скрывает проблему и создаёт дополнительную нагрузку.

Обеспечьте безопасность повтора

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

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

Сделайте очередь наблюдаемой

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

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

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

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

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

Пример восстановления накопившейся очереди

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

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

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

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

Как делить лимит API между сайтом и фоновым импортом

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

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