Rate limit, 429 e upgrade di tier
Aggiornato September 1, 2026 · pubblicato inizialmente September 1, 2026
Quando un servizio comincia a restituire 429, il riflesso è trattarlo come un incidente di disponibilità: alzare il limite, passare a un tier superiore, aggiungere retry, ripristinare il throughput. A volte è giusto. È anche il meccanismo con cui un loop fuori controllo diventa una fattura a cinque cifre, perché l'unica cosa che lo fermava è appena stata rimossa.
Cosa ti dice davvero un 429
Dice che il sistema prova a spendere più in fretta della sua allocazione. Succede per due ragioni molto diverse, che richiedono risposte opposte. Crescita reale della domanda — più utenti, un lancio, un picco stagionale — significa che il limite è davvero troppo basso e alzarlo genera ricavi reali. Comportamento fuori controllo — una tempesta di retry, un agente in loop, un backfill senza throttling, una suite di test puntata alle chiavi di produzione — significa che il limite sta facendo esattamente il suo lavoro.
Le due situazioni non si distinguono dal solo tasso di errore. Si distinguono facilmente guardando il costo per unità di lavoro: la crescita reale mantiene il rapporto più o meno costante mentre il volume sale; un loop fuori controllo lo spezza, spendendo molto di più per attività completata rispetto al giorno prima. Questo singolo rapporto dovrebbe decidere ogni upgrade di tier.
I retry peggiorano le cose, in silenzio
Un retry ingenuo sui 429 senza backoff esponenziale e jitter trasforma una violazione del limite in una tempesta sincronizzata. Le richieste che riescono vengono fatturate; molte di quelle che falliscono hanno comunque consumato elaborazione dell'input. E poiché i retry sono di solito implementati nella libreria client e non nel codice applicativo, l'amplificazione non compare da nessuna parte nei documenti di design della funzionalità.
Usa i limiti in modo deliberato
Imposta i tuoi limiti sotto quelli del provider, per ambiente e per funzionalità, così il primo a rompersi è il tuo e controlli cosa succede dopo. Mantieni il non-produzione strettamente limitato: una build di test fallita costa poco, un percorso cliente limitato no. Allerta sul rapporto costo per attività, non solo sui conteggi degli errori. E quando fai un upgrade di tier, trattalo come una decisione di spesa con un responsabile nominato, perché è esattamente questo.
Correlati
Correlati
Vuoi applicarlo al tuo stack? Porta le fatture dei provider, i log del gateway e i flussi di lavoro principali: mapperemo i costi e i possibili risparmi. Prenota un audit gratuito →