Заказы остаются на сайте, а в CRM появляются с задержкой; в журнале обмена повторяется 429 Too Many Requests. Такой ответ означает ограничение частоты запросов. Чтобы восстановить обмен, нужно согласовать общий темп отправки с лимитами провайдера, сохранить ожидающие операции и разрешать повторы только по понятному правилу.
Руководителю проекта до изменения настроек полезно сделать три безопасных шага:
- Зафиксировать время ошибки, название операции, код ответа и наличие
Retry-After. Не копировать токены, персональные данные и полные тела запросов. - Посмотреть число ожидающих операций и возраст самой старой по штатному отчёту. Не запускать переотправку для проверки.
- Сопоставить документацию API — интерфейса обмена между системами — со всеми отправителями: сайтом, фоновыми заданиями и ручными выгрузками.
Ниже — способ поставить задачу на доработку и проверить результат. Лимиты и допустимую задержку нужно уточнять для конкретного сервиса.
Сначала выясните, какой лимит срабатывает
По RFC 6585, раздел 4, код 429 связан со слишком большим числом запросов за период. Ответ может содержать Retry-After, но этот заголовок необязателен. Стандарт не устанавливает единую квоту и не определяет, как провайдер считает запросы.
Поэтому настройки одного модуля недостаточно. Например, два обработчика могут по отдельности соблюдать свой предел, но вместе превышать квоту общей учётной записи. Это гипотеза для проверки по документации и журналу, а не диагноз по одному коду ошибки.
Составьте короткий паспорт ограничений:
| Что уточнить | Что записать для разработчика |
|---|---|
| Область квоты | Учётная запись, приложение, отдельный метод или другой объект по правилам API |
| Период и объём | Документированный предел и способ отсчёта окна |
| Одновременные запросы | Отдельное ограничение параллельности, если оно есть |
| Общие потребители | Какие модули используют ту же квоту |
| Поведение при отказе | Код, пояснение, наличие и формат времени ожидания |
| Допустимое отставание | Когда задержка становится проблемой для заказа, остатка или заявки |
Если сведения неизвестны, их нужно уточнить у провайдера. Увеличение числа обработчиков без этого может усилить отказ. Ротация ключей или адресов ради обхода ограничений не решает задачу устойчивого обмена.
Разделите ожидание, повтор и ошибку, требующую разбора
Очередь должна показывать, что происходит с каждой операцией. «Не отправлено» слишком неопределённо: это может быть плановое ожидание квоты, временный отказ, неизвестный результат или ошибка данных.
Для постановки задачи подойдёт такая схема:
- Ожидает отправки. Операция сохранена, есть время следующей попытки. До него обработчик не обращается к провайдеру.
- Временно ограничена. Получен подтверждённый отказ по квоте; повтор планируется по правилам API и учитывается в общем бюджете запросов.
- Результат неизвестен. Ответ потерян либо обработка не завершена. Сначала требуется предусмотренная сервисом сверка результата.
- Нужен разбор. Данные неприемлемы, доступ не действует или исчерпаны согласованные попытки. Запись остаётся видимой, назначается ответственный.
Это предлагаемая модель состояний, а не обязательный формат любого API. Её нужно согласовать с устройством проекта. Не следует превращать каждый ответ 4xx в одинаковый повтор: ошибка полей или прав обычно требует другого действия, чем ограничение квоты.
Сохранение операции и подтверждение её приёма должны быть согласованы: после перезапуска задача не должна исчезнуть между этими этапами. Счётчик попыток и запланированная пауза тоже должны переживать перезапуск.
Не очищайте очередь ради «зелёного» отчёта. Если автоматическая обработка остановлена, данные и причина остановки должны остаться доступными для сверки.
Настройте паузу и общий темп отправки
RFC 9110, раздел 10.2.3, описывает два формата Retry-After: число секунд после получения ответа либо HTTP-дату. Обработчик должен понимать оба варианта. Некорректное значение нельзя молча считать нулевой паузой: нужен заранее согласованный запасной порядок.
При допустимом повторе учитывают указание провайдера и общий ограничитель отправки. Если время ожидания больше допустимого срока операции, её передают на разбор, а не отправляют раньше. Отсутствие заголовка также не означает разрешения немедленно повторять запрос.
В документации AWS Retry with backoff предлагается увеличивать интервалы между повторными попытками временно неудачных операций и ограничивать число попыток. Материал Timeouts, retries, and backoff with jitter объясняет случайный разброс пауз: он помогает обработчикам не повторять запросы одновременно. Такой разброс не должен сокращать обязательное ожидание провайдера.
В проекте нужно определить одного владельца повторов. Если библиотека, очередь и прикладной код повторяют независимо, фактических обращений может стать больше, чем показывает счётчик одного слоя. Проверять следует весь путь отправки.
Общая квота должна учитывать новые операции, повторы и другие интеграции. При восстановлении после паузы нельзя выпускать всю накопленную очередь разом.
Рассчитайте, сможет ли очередь сократиться
Отсутствие новых 429 ещё не доказывает восстановление. Если обработка идёт медленнее поступления задач, задержка продолжит расти.
Учебный расчёт, не показатель клиентского проекта. Допустим, API разрешает 100 запросов в минуту. С учётом остальных потребителей для этой очереди согласовали равномерную обработку 80 операций в минуту, по одному запросу на операцию. Новых операций приходит 50 в минуту, накопилось 600.
При неизменных условиях на сокращение отставания остаётся 80 − 50 = 30 операций в минуту. Расчётное время — 600 / 30 = 20 минут. Это оценка без повторных отказов, дополнительных запросов и других задержек; её нельзя обещать как срок восстановления.
Если входящий поток достигнет 80 операций в минуту, запаса для сокращения очереди уже не будет. Нужны согласованные изменения: убрать лишние обращения, применить поддерживаемые пакетные операции, изменить расписание второстепенных выгрузок или обсудить квоту с провайдером.
Смотрите не только на длину очереди, но и на возраст старейшей задачи, скорость поступления, число успешно завершённых операций и долю повторов. Порог уведомления выбирают по последствиям задержки для бизнеса. Для остатков и справочной информации он может отличаться.
Сохраните результат при повторе и восстановлении
Пауза уменьшает нагрузку, но сама по себе не защищает от второго заказа. Для операций с побочными эффектами нужно подтвердить допустимость повтора: поддержку идемпотентности, то есть одного результата при повторном выполнении, или способ узнать исход первой попытки.
Ключ операции, срок его действия и правила изменения данных определяет конкретный API. Подробно этот отдельный сценарий разобран в статье о повторной отправке заказа после таймаута.
После длительной паузы часть задач может устареть. Например, прежнее значение остатка уже заменено новым. Команда должна определить, какие обновления можно объединять, а какие события необходимо обработать отдельно и в правильном порядке. Автоматически отбрасывать заказы по правилу для справочных данных нельзя.
В плане восстановления зафиксируйте, кто разрешает возобновление, как проверяется актуальность задач и куда попадают спорные операции. Массовая переотправка без сверки не должна быть единственным способом «починить обмен».
Принимайте доработку по сценариям, а не одному успешному запросу
Попросите разработчика проверить модель на изолированном контуре с искусственными данными и имитацией ответов провайдера. Реальные платежи, письма, заказы и обмен с рабочим складом в такой проверке не участвуют.
Минимальный протокол приёмки:
- При
429задача сохраняется, повтор не происходит раньше разрешённого времени; проверены оба форматаRetry-Afterи его отсутствие. - Два обработчика вместе соблюдают общую квоту, включая повторные попытки; перезапуск не сбрасывает ожидание.
- Ошибка данных и исчерпание попыток переводят операцию на видимый разбор, без бесконечного цикла.
- При потерянном ответе система сверяет результат или применяет подтверждённую защиту от дубля.
- После паузы задачи обрабатываются в допустимом темпе; устаревшие события проходят согласованную проверку.
- Для заданного входящего потока очередь сокращается; превышение порога возраста вызывает уведомление ответственному.
В отчёте нужны условия опыта, ожидаемое и фактическое состояние очереди и конечной системы. Запись «запрос успешен» не подтверждает, что все операции дошли и данные согласованы.
Когда достаточно своей команды, а когда нужна помощь
Если у команды есть документация API, контроль над всеми отправителями, наблюдаемая очередь и тестовый контур, паспорт ограничений и эти сценарии можно использовать самостоятельно. Привлекать внешних специалистов уместно, когда обмен унаследован, квота разделена между подрядчиками или неизвестно, что произойдёт после возобновления очереди.
OpenStart выполняет доработки сайтов и интеграций с CRM и API. Для такой задачи сначала нужно согласовать диагностику, границы изменения и проверяемый результат; увеличение лимита или срок восстановления заранее обещать нельзя.
Передайте задачу на оценку доработки: достаточно описать задержку, участвующие системы и ожидаемый результат. Менеджер уточнит вводные для согласования первого этапа. Пароли, токены и выгрузка клиентской базы для первого обращения не нужны.