IOSOR

IOSOR База знаний

Лимиты API от пилота к production: backoff без сжигания prepaid

Лимиты пилота и production, экспоненциальный backoff, идемпотентность, ключи sandbox vs production и ограниченное окно replay webhook — чтобы retry не опустошали prepaid-кошелёк.

429 — не приглашение долбить send API, пока что-то не пройдёт. На prepaid retry-шторм — событие кошелька: дубль OTP, стопка алертов, несопоставимые строки ledger. Rate limits существуют, чтобы продукт, engineering и финансы делили один потолок. Путь от пилота к production — не «снять cap». Это договорные лимиты, backoff, который уважает идемпотентность, раздельные ключи sandbox и production, и окно replay webhook, которое не списывает дважды. Держите рядом идемпотентность, retry и деньги.

IOSOR — white-label prepaid: аутентифицированные вызовы, сопоставимые debit, client-safe ошибки без чужих брендов.

Лимиты защищают prepaid, это не баг

Лимиты — контроль денег. Они ограничивают, сколько принятых intent попадает в кошелёк за окно — не сколько TCP-попыток сделал балансировщик. Документируйте окно (на ключ, аккаунт, класс направления), код статуса и контракт Retry-After. Клиент, который читает 429 как «дави сильнее», выигрывает гонку у финансов. Выгружайте отказы лимита рядом с успешными debit, чтобы всплеск был дашбордом, не сюрпризом.

Backoff без второго debit: лимиты вместе с идемпотентностью

Экспоненциальный backoff без ключа идемпотентности — как из дёрганой сети получаются два OTP. Ключ уникален на бизнес-intent, не на TCP-попытку, и возвращает тот же accepted результат внутри явного TTL. User resend — другое продуктовое действие со своим лимитом; не смешивайте с auto-retry. Stop-on-low-balance действует: retry не должен пробивать пустой кошелёк.

Лимиты пилота vs лимиты production

Пилотные ключи намеренно туже: низкий объём, быстрая видимость, дешёвые ошибки. Production-лимиты договорные под коридоры, которые вы реально гоняете — не скопированы из блога. Поднять потолок — изменение аккаунта с owner, не скрытый header. Нагрузочные тесты — на sandbox-ключах с sandbox-reachability; production-ключ в soak — сжигание prepaid. Не обещайте production QPS, пока коридор каталога in setup.

Ключи и replay webhook в одном cutover

Лимиты на send не спасут, если consumer webhook дважды обработает DLR. Cutover: заморозить sandbox-трафик, выдать production-ключи, направить webhook на production consumers, проверить подписи, ограничить окно replay, затем один реальный intent. Повторный callback в 02:00 — no-op, не второй debit. Разведите секреты sandbox и production; ни один не вставляйте в тикет.

Красные флаги

  • «Retry until 200» без ключа идемпотентности
  • 429 как мягкий 200
  • Production-ключ в нагрузочном тесте или sandbox webhook URL в production
  • Окно replay

Старт с IOSOR

Запишите окно лимита — на ключ, аккаунт или класс направления — и Retry-After, который будете чтить. Вызовите 429, сделайте backoff и повторите то же намерение тем же Idempotency-Key. В ledger должен быть один debit. Смените sandbox-ключ на production, прежде чем поднимать потолок.

Итог IOSOR

Делайте: считайте 429 паузой с Retry-After, не мягким успехом. Каждый backoff сопровождайте исходным ключом, чтобы prepaid увидел одно принятое намерение.

Не делайте: поднимать production-лимиты на ключе нагрузочного теста и долбить до 200 без ключа, пока кошелёк не станет похож на лишний расход.

Был ли материал полезен?

Связанные гайды