Limiti API dal pilota alla produzione: backoff senza bruciare prepaid

Un 429 non invita a martellare l’API di invio finché qualcosa passa. Su prepaid, una tempesta di retry è un evento di wallet: OTP duplicato, alert impilati, righe di ledger senza coppia. I limiti esistono perché prodotto, engineering e finance condividano un tetto. Dal pilota alla produzione non è «togliere il cap» — limiti contrattati, backoff che rispetta l’idempotenza, chiavi sandbox e produzione separate, e una finestra di replay webhook che non doppio-addebita. Vedere idempotenza, retry e denaro.

IOSOR è prepaid white-label: chiamate autenticate, debiti correlabili, errori sicuri per il cliente che non scaricano mai payload di un altro brand.

I limiti proteggono prepaid, non sono un bug

I limiti delimitano quanti intent accettati colpiscono il wallet per finestra — non quante tentativi TCP ha fatto il bilanciatore. Documentate la finestra (per chiave, conto, classe di destinazione), il codice e Retry-After. Un client che tratta 429 come «prova più forte» corre contro finance. Esportate i reject di limite accanto ai debiti riusciti.

Backoff senza secondo debito: limiti con idempotenza

Backoff esponenziale senza chiave di idempotenza è come una rete instabile diventa due OTP. La chiave è unica per intent di business, non per tentativo TCP, e restituisce lo stesso risultato accettato dentro un TTL chiaro. Il reinvio utente è un’altra azione di prodotto con il proprio limite. Lo stop a saldo basso vale: un retry non deve forare un wallet vuoto.

Limiti pilota versus produzione

Le chiavi pilota devono essere più strette: basso volume, visibilità rapida, errori economici. I limiti produzione sono contrattati per i corridoi che fate girare davvero. Alzare un tetto è un cambio di conto con proprietario. I test di carico appartengono alle chiavi sandbox; una chiave produzione in un soak brucia prepaid. Non promettete QPS di produzione finché il corridoio catalogo è in setup.

Chiavi e replay webhook nello stesso cutover

I limiti di invio non salvano se il consumer webhook processa due volte un DLR. Cutover: congelare il traffico sandbox, emettere chiavi produzione, puntare i webhook ai consumer produzione, verificare le firme, delimitare la finestra di replay, poi un intent reale. Un callback ripetuto alle 02:00 deve essere no-op, non un secondo debito. Segreti separati; non incollateli mai in un ticket.

Bandiere rosse

• «Retry fino a 200» senza chiave di idempotenza
• 429 trattato come un 200 morbido
• Chiave produzione in un test di carico o URL webhook sandbox in produzione
• Finestra di replay misurata in settimane, o callback non firmati «per il pilota»
• Reinvio utente mescolato nel budget di auto-retry
• Errori client che scaricano codici grezzi a monte

Iniziare con IOSOR

Annotate la finestra di limite — per chiave, conto o classe di destinazione — e il Retry-After che onorerete. Forzate un 429, fate backoff e ritentate lo stesso intento con la stessa Idempotency-Key. Il ledger deve mostrare un addebito. Sostituite la chiave sandbox con quella production prima di alzare un tetto.

• Tracciamento degli ID di correlazione dalle richieste API ai webhook DLR
• Simulazione di latenza ed errori DLR nei test locali

Sintesi IOSOR

Fate: trattate il 429 come una pausa con Retry-After, non come un successo morbido. Accoppiate ogni backoff alla chiave originale così il prepaid vede un intento accettato.

Non fate: alzare i limiti production su una chiave di load test, né martellare fino a 200 senza chiave finché il portafoglio sembra uso extra.