Errore 429: cos’è il rate limiting e come usarlo

Ti è mai successo di entrare su una piattaforma e all’improvviso vedere una funzionalità bloccata, se non l’intera pagina, per via di un HTTP error 429, “Too Many Requests”? La ragione è da ricercarsi nel rate limiting.

Certamente da utente può essere fastidioso, ma si tratta in realtà di una sensata scelta di progettazione; prima o poi chiunque sviluppi API si trova a dover implementare questo tipo di controllo. Vediamo quindi come e perché imporre una limitazione ai propri utenti.

Cos’è il rate limiting

Il rate limiting è una regola che limita quante volte un soggetto può eseguire una determinata operazione in un certo periodo. Per esempio, stabilisce che l’utente:

• Può provare a fare login fino a 5 volte al minuto, 
• Oppure, che può creare fino a 100 task al minuto, 
• O ancora, che il limite di chiamate di qualsiasi tipo è non oltre le 1000 all’ora.

Da cosa è composto il limite

Ci sono quattro componenti che intervengono nella limitazione della frequenza. Da un lato, il soggetto limitato. Può essere identificato in modo diverso:

• Dal proprio indirizzo IP, 
• Con il proprio profilo utente,
• Con il proprio tenant (ad esempio, identificherà tutti gli utenti di un’azienda in un SaaS)
• Attraverso l’API key utilizzata.

Una secondo componente è la risorsa od operazione che viene limitata. Infatti, può essere limitata una singola chiamata, come nell’esempio del login precedentemente portato, oppure possono essere limitate tutte le chiamate congiuntamente, con un limite settato globalmente a prescindere dagli endpoint.

Strettamente legati alla risorsa sono il limite che viene imposto (ad esempio, 100 chiamate) e il range temporale (in un minuto, in un’ora, ecc.).

Come l’utente si scontra con il limite

Per ogni chiamata, viene identificato il soggetto e il limite da applicare. A quel punto il sistema controlla quanto è già stato consumato, e decide se proseguire con la chiamata (e aggiornare il consumo) oppure bloccarla.

In una API HTTP, al limite superato corrisponde un messaggio di errore di tipo “Too Many Requests”. Il messaggio da comunicare all’utente è importante tanto quanto l’applicazione del limite, perché:

• Guida l’utente attraverso quello che sta succedendo.
• Può anche fornire informazioni aggiuntive, come quanto attendere prima di riprovare.

Inoltre, lasciare l’utente in sospeso, senza un feedback, può portarlo a percepire l’errore come un bug, diminuendo la sua fiducia nell’applicazione e spingendolo a ritentare immediatamente, peggiorando il problema che il limite doveva risolvere.

In caso di limiti facili da raggiungere, è auspicabile esporre preventivamente i limiti, in modo che il client possa prevenire la situazione in cui il limite è raggiunto. Ad oggi non esiste uno standard per comunicare dopo quanto riprovare, quanta disponibilità rimane o quando il limite si resetta. 

Perché prevedere un rate limit prima di averne bisogno

Lo so cosa stai pensando: “La mia API è usata da 10 persone, chi vuoi che mi attacchi?”. Ma il rate limiting non serve solo per prevenire attacchi: può anche prevenire incidenti se il client è scritto male o se un retry automatico porta ad un loop delle richieste.

È quindi una buona pratica aggiungere il limite quando il sistema è tranquillo, perché quando serve è già tardi: il servizio non sta funzionando e nel peggiore dei casi può essere un errore molto costoso.

Cosa succede quando non c’è un limite

La ragione principale per implementare un limite è la difesa:

• Alcuni endpoint possono usare servizi o API a pagamento e un abuso può letteralmente incidere sull’economia del tuo prodotto.
• Anche nel migliore dei casi, c’è la possibilità che l’assenza di un limite porti a un sovraccarico del sistema.

Concretamente, se un login non ha limiti è vulnerabile al brute force, cioè un cyberattacco basato su tentativi ed errori, nel tentativo di imbroccare le credenziali corrette.

O ancora, se un endpoint usa un servizio, solitamente a pagamento, per l’invio di SMS o email, ad esempio per il reset di una password, la mancanza di limiti può portare a prosciugare il budget in pochi minuti. Perciò, tutto sommato, meglio prevenire che curare.

Non solo difesa: è anche distribuzione delle risorse

Il rate limiting non è solamente una pratica difensiva. Si tratta di una scelta di prodotto. Un limite ben progettato, infatti:

• Evita che un singolo utente consumi troppe risorse.
• Distribuisce equamente le risorse tra gli utenti.

Il limite spesso è il confine tra diversi piani commerciali di un prodotto. Questo è molto comune anche nelle API di modelli linguistici, che non si limitano a contare le richieste, ma le affiancano a metriche come le requests per minute (RPM) o i tokens per minute (TPM). È questo il caso, ad esempio, delle API di OpenAI.

In questo caso, l’errore più pertinente non è il nostro 429, ma 402, Payment Required, che sebbene non sia un errore standard per questa casistica è più specifico.

Come mettere un rate limit

“100 richieste al minuto” sembra un limite chiaro, no? E invece, lascia delle ambiguità: sono 100 richieste negli ultimi 60 secondi, o 100 entro le 12:00 e le 12:01, oppure c’è una riserva che si rigenera nel tempo?

La risposta a questa domanda varia a seconda dell’algoritmo implementato.

Contare il tempo: fixed window e sliding window

Il modo più intuitivo per implementare l’algoritmo è quello che include una finestra temporale. Questa finestra, però, può essere intesa in maniere diverse. 

Da un lato abbiamo una finestra temporale fissa, la cosiddetta fixed window, che riparte da zero a ogni minuto. Ha il vantaggio di essere molto semplice da implementare e da mantenere, richiedendo solo di mantenere un contatore che aumenta a ogni richiesta.

Ovviamente, però, presenta anche degli svantaggi, in primis quello per cui se vengono eseguite 100 richieste alle 12:00:59 e altre 100 alle 12:01:00, nessun limite viene formalmente violato.

L’alternativa è implementare un tipo di finestra differente, calcolata negli ultimi 60 secondi dal momento corrente. Questa è detta sliding window e previene la situazione precedentemente citata. 

Ne esistono più varianti, tra cui la sliding window log, che salva timestamp per ogni richiesta, con un maggior costo di memoria ma una perfetta precisione, oppure lo sliding window counter, che usa dei contatori ma approssima il valore.

Gestire i picchi: token bucket e leaky bucket

Altri metodi, anziché concentrarsi sul conto del tempo, sono più progettati per regolare il flusso. 

Nel token bucket ogni utente ha un “secchio” di token, ogni operazione ne consuma uno e questi si rigenerano nel tempo, ma mai fino a straripare dal secchio. Quindi ad esempio, un utente può avere 100 token, ogni richiesta ne richiede uno e ogni secondo vengono ricaricati circa 2 token.

Perciò, se la disponibilità è massima, 10 richieste passano immediatamente. Se invece il secchio è vuoto, la richiesta verrà bloccata; ma dopo un secondo sarà possibile fare due nuove operazioni.

I fattori che possono essere controllati sono quindi due:

• La capacity, cioè quante richieste possono venir fatte immediatamente.
• Il refill rate, cioè quanto velocemente è possibile farne altre.

Il leaky bucket, invece, regolarizza il flusso di richieste. Le operazioni entrano in coda e vengono elaborate a una velocità costante. Rendendo il traffico al server regolare, impedisce picchi di richieste alla risorsa protetta.

Algoritmi diversi, per quanto tutti validi, rispondono a esigenze diverse. Riassumendo: 

In conclusione, la scelta dell’algoritmo di rate limiting ha un ruolo importante, ma non conta quanto saper scegliere bene dove applicarlo, con quali limiti e cosa succede quando il limite viene superato. 

Se vuoi una consulenza su come strutturare l’architettura del tuo backend e le tue API, non esitare a contattarci. Saremo pronti a darti una mano e a suggerirti tanti altri modi per rendere il tuo prodotto digitale più sicuro ed efficiente.