Limites de API do piloto à produção: backoff sem queimar prepaid

Um 429 não convida a martelar a API de envio até algo passar. Em prepaid, uma tempestade de retry é um evento de carteira: OTP duplicado, alertas empilhados, linhas de ledger sem par. Limites existem para produto, engenharia e finanças partilharem um teto. De piloto a produção não é «tirar o cap» — limites contratados, backoff que respeita idempotência, chaves sandbox e produção separadas, e uma janela de replay de webhook que não duplo-debita. Veja idempotência, retries e dinheiro.

IOSOR é prepaid white-label: chamadas autenticadas, débitos correlacionáveis, erros seguros para o cliente que nunca despejam cargas de outra marca.

Limites protegem prepaid, não são um bug

Limites limitam quantos intents aceites batem na carteira por janela — não quantas tentativas TCP o balanceador fez. Documentem a janela (por chave, conta, classe de destino), o código e Retry-After. Um cliente que trata 429 como «tenta mais forte» corre contra finanças. Exportem rejeições de limite junto a débitos bem-sucedidos.

Backoff sem segundo débito: limites com idempotência

Backoff exponencial sem chave de idempotência é como uma rede instável vira dois OTP. A chave é única por intent de negócio, não por tentativa TCP, e devolve o mesmo resultado aceite dentro de um TTL claro. Reenvio do utilizador é outra ação de produto com o seu limite. Stop de saldo baixo aplica-se: um retry não deve perfurar uma carteira vazia.

Limites de piloto versus produção

Chaves de piloto devem ser mais apertadas: baixo volume, visibilidade rápida, erros baratos. Limites de produção são contratados para os corredores que realmente correm. Subir um teto é uma mudança de conta com dono. Testes de carga pertencem a chaves sandbox; uma chave de produção num soak queima prepaid. Não prometam QPS de produção enquanto o corredor do catálogo estiver in setup.

Chaves e replay de webhook no mesmo cutover

Limites de envio não salvam se o consumidor de webhook processar DLR duas vezes. Cutover: congelar tráfego sandbox, emitir chaves de produção, apontar webhooks a consumidores de produção, verificar assinaturas, limitar a janela de replay, depois um intent real. Um callback repetido às 02:00 deve ser no-op, não um segundo débito. Segredos separados; nunca os colem num ticket.

Sinais de alerta

• «Retry até 200» sem chave de idempotência
• 429 tratado como um 200 mole
• Chave de produção num teste de carga ou URL de webhook sandbox em produção
• Janela de replay medida em semanas, ou callbacks sem assinatura «para o piloto»
• Reenvio do utilizador misturado no orçamento de auto-retry
• Erros de cliente que despejam códigos crus de cima

Começar com IOSOR

Anote a janela de limite — por chave, conta ou classe de destino — e o Retry-After que honrará. Force um 429, recue, depois reenvie a mesma intenção com a mesma Idempotency-Key. O ledger deve mostrar um débito. Troque a chave sandbox pela de production antes de subir qualquer teto.

• Rastreamento de IDs de correlação de solicitações de API para webhooks DLR
• Simulando latência e erros de DLR em testes locais

Conclusão IOSOR

Faça: trate o 429 como uma pausa com Retry-After, não como um sucesso mole. Emparelhe cada backoff com a chave original para o prepaid ver uma intenção aceite.

Não faça: subir limites de production numa chave de teste de carga, nem martelar até 200 sem chave até a carteira parecer uso extra.