Che cos'è il rate limiting? Guida semplice per chi crea app

Il rate limiting è una regola che limita quante richieste una persona può fare a un sistema in un determinato intervallo di tempo, ad esempio 5 tentativi di accesso al minuto o 100 chiamate API all'ora. Una volta raggiunto il limite, le richieste successive vengono rifiutate (di solito con il codice di errore 429 Too Many Requests) finché la finestra temporale non si resetta. Protegge le app dagli abusi, impedisce che un utente molto attivo rallenti le cose per tutti e ferma i costi fuori controllo.

Incontri il rate limiting da due lati: i servizi che chiami limitano te, e la tua app dovrebbe limitare i propri utenti.

Perché il rate limiting conta quando crei con l'AI

Le app create con l'AI spesso si collegano a servizi a pagamento (modelli AI, email, SMS, mappe), e ogni chiamata costa denaro. Questo rende il rate limiting sia una funzione di sicurezza sia una funzione di controllo del budget.

Controllo dei costi. Se la tua app ha una casella « chiedi all'AI » e nessun limite, un bot può inviarle migliaia di richieste durante la notte. Paghi ogni singola richiesta.
Sicurezza. Senza un limite sul modulo di accesso, un attaccante può provare migliaia di password su un account. Un limite di pochi tentativi al minuto rende questo poco pratico.
Restare online. Uno script malfunzionante, a volte il tuo stesso codice bloccato in un ciclo, può sovraccaricare il database e far cadere l'app.
Rispettare i limiti degli altri servizi. Quando la tua app chiama un'API esterna troppo spesso, sei tu a ricevere gli errori 429, e le funzioni si rompono per i tuoi utenti.

I builder AI costruiscono quello che chiedi. Se non menzioni i limiti, spesso vengono lasciati fuori.

Un'analogia quotidiana

Pensa alla politica del bar: « Un rabbocco gratuito per cliente a visita. »

Non impedisce a nessuno di godersi il caffè.
Impedisce a una persona di stare al banco tutto il giorno a riempire un thermos per tutto l'ufficio.
Quando qualcuno chiede un quarto rabbocco, il barista dice gentilmente « non adesso »: questo è il 429.

Un buon limite di frequenza è invisibile ai clienti normali e si nota solo se qualcuno fa qualcosa di insolito.

Come funziona il rate limiting

Un limitatore di frequenza ha bisogno di tre elementi:

Elemento	Domanda a cui risponde	Esempi
Chi	Di chi vengono contate le richieste?	Per account utente, per indirizzo IP, per chiave API
Quante	Qual è il limite?	5, 60, 1.000 richieste
In quale tempo	In quale finestra?	Al secondo, al minuto, all'ora, al giorno

Quando arriva una richiesta, l'app controlla il conteggio per quel « chi ». Sotto il limite: la richiesta passa e il conteggio aumenta. Sopra il limite: la richiesta viene rifiutata.

Ci sono alcuni modi comuni di contare:

Metodo	Come funziona	Compromesso
Finestra fissa	Il conteggio si azzera sull'orologio, ad esempio ogni minuto al minuto esatto	Semplice, ma permette un picco al confine tra due finestre
Finestra scorrevole	Guarda gli ultimi 60 secondi a partire da adesso	Più uniforme, leggermente più costoso da calcolare
Token bucket (secchio di gettoni)	Ogni utente ha un secchio che si riempie a velocità costante; ogni richiesta consuma un gettone	Permette brevi picchi mantenendo stabile la media

I conteggi devono essere memorizzati in un posto veloce e condiviso. Su un piccolo server singolo basta la memoria. Quando un'app gira su più macchine, il contatore di solito vive in un archivio condiviso come Redis o il database, altrimenti ogni macchina conta per conto suo e il limite reale diventa diverse volte più alto.

Come appare una risposta limitata

Quando una richiesta supera il limite, un'API ben progettata risponde con:

Codice di stato 429 Too Many Requests.
Spesso un header Retry-After, che indica quanti secondi attendere.
A volte header che mostrano il tuo limite e quante richieste ti restano in questa finestra (i nomi variano a seconda del fornitore).

La tua app dovrebbe rispondere a un 429 aspettando e riprovando più tardi, idealmente con backoff esponenziale, cioè aspettando un po' di più dopo ogni tentativo fallito (1 secondo, poi 2, poi 4) invece di bombardare il servizio.

Un esempio pratico: un assistente di scrittura con AI

Supponiamo di aver creato un'app in cui gli utenti incollano un testo e ricevono una riscrittura dall'AI.

Senza limiti: qualcuno scrive uno script che invia 20.000 richieste durante la notte. La bolletta del tuo fornitore di AI schizza, e il tuo account raggiunge il limite di frequenza del fornitore, quindi gli utenti reali vedono errori per tutta la mattina.

Con limiti sensati:

Per utente connesso: 30 riscritture all'ora nel piano gratuito, 300 nel piano a pagamento. Oltre il limite, l'utente vede: « Hai raggiunto il limite di questa ora. Riprova tra 12 minuti oppure passa a un piano superiore. »
Per indirizzo IP sul modulo di registrazione: 5 registrazioni all'ora, per impedire ai bot di creare migliaia di account gratuiti per aggirare il limite per utente.
Un limite di spesa impostato nella dashboard del fornitore di AI, come ultima linea di difesa se tutto il resto fallisce.
Gestire i limiti del fornitore: se il fornitore di AI restituisce un 429, il tuo server attende e riprova una o due volte, poi mostra un messaggio gentile del tipo « servizio occupato, riprova ».

I limiti vanno controllati sul server. Un limite che esiste solo nel browser, ad esempio disattivare il pulsante dopo 30 clic, può essere aggirato da chiunque chiami direttamente la tua API.

Termini chiave

Termine	Significato
Rate limit	Il numero massimo di richieste consentite in una finestra temporale.
Quota	Un'allocazione più ampia, spesso giornaliera o mensile, talvolta legata a un piano a pagamento.
429	Il codice di stato HTTP per « troppe richieste ».
Retry-After	Un header di risposta che indica quanto attendere prima di riprovare.
Throttling	Rallentare o rifiutare le richieste oltre un limite. Spesso usato come sinonimo.
Backoff esponenziale	Attendere progressivamente di più tra un tentativo e l'altro.
Burst (raffica)	Un breve picco di molte richieste in una volta.
Attacco brute-force	Provare un numero enorme di password o codici finché uno funziona.

Idee sbagliate comuni

« Il rate limiting serve solo alle app grandi. » Anche le app piccole sono bersagli, perché i bot esplorano tutta la rete alla ricerca di moduli aperti ed endpoint AI. Il costo di un abuso non dipende dalle dimensioni della tua app.
« Nascondere il pulsante basta. » I limiti lato browser sono una cortesia, non una protezione. I limiti veri vanno applicati sul server.
« I limiti per IP sono sempre equi. » Molte persone possono condividere un indirizzo IP: un ufficio, una scuola, una rete mobile. Una volta che le persone hanno effettuato l'accesso, i limiti per utente sono più equi.
« Un 429 significa che il servizio è guasto. » Significa che lo stai chiamando troppo spesso. Controlla il tuo codice per cercare cicli e memorizza nella cache i risultati che cambiano poco spesso: vedi cos'è la cache.
« Il rate limiting sostituisce un limite di spesa. » Usali entrambi. I limiti nella tua app possono avere bug; il limite di spesa del fornitore è il tuo paracadute.

Cosa chiedere al tuo builder AI

« Aggiungi il rate limiting lato server a login, registrazione, reimpostazione della password ed endpoint AI. Suggerisci limiti sensati. »
« Limita ogni utente connesso a [N] richieste AI all'ora e mostra un messaggio chiaro con il tempo di attesa quando raggiunge il limite. »
« Quando un'API esterna restituisce 429, riprova con backoff esponenziale fino a 3 volte, poi mostra un errore gentile. »
« Dove vengono memorizzati i contatori del rate limit? Continueranno a funzionare se l'app gira su più macchine? »
« Registra ogni volta che un utente o un IP raggiunge un limite, così posso individuare gli abusi. »
« Quali servizi esterni chiama questa app e quali sono i loro limiti di frequenza? »

Il rate limiting in Mythex

La documentazione di Mythex è diretta su questo punto per le funzioni AI: limiti di frequenza, sicurezza e controlli dei costi nelle app che crei sono di tua responsabilità da progettare, vedi Creare un'app AI. Chiedi all'agente di aggiungere i limiti nello stesso messaggio in cui chiedi la funzione. Nel piano Pro un servizio pubblicato può girare su fino a tre macchine quando il traffico è intenso (vedi Limiti di hosting), quindi chiedi contatori che vivano nel database invece che nella memoria di un singolo server.

Letture correlate: cos'è un'API, come usare le API degli LLM e la checklist di sicurezza per le app create con l'AI.

Domande

Che cos'è il rate limiting in parole semplici?

Il rate limiting è una regola che limita quante richieste un utente, un dispositivo o un'app può fare in un determinato periodo, ad esempio 5 tentativi di accesso al minuto o 100 chiamate API all'ora. Le richieste oltre il limite vengono rifiutate finché la finestra temporale non si resetta.

Che cosa significa l'errore 429 Too Many Requests?

Lo stato HTTP 429 significa che hai inviato troppe richieste in un tempo troppo breve e hai raggiunto un limite di frequenza. La risposta spesso include un header Retry-After che indica quanto attendere. La soluzione è rallentare, riprovare dopo una pausa o ridurre la frequenza con cui l'app chiama il servizio.

Perché la mia app basata sull'AI ha bisogno del rate limiting?

Ogni richiesta AI ti costa denaro in token. Senza un limite, un utente o un bot può inviare migliaia di richieste, far salire una bolletta enorme o esaurire la quota del fornitore, mettendo fuori servizio la funzione per tutti. I limiti per utente rendono i costi prevedibili.

Il rate limiting è la stessa cosa del throttling?

Sono strettamente collegati e spesso usati come sinonimi. Il rate limiting di solito significa rifiutare le richieste oltre un limite, mentre il throttling può anche significare rallentarle o metterle in coda invece di rifiutarle del tutto.

Il rate limiting ferma gli attacchi DDoS?

Aiuta contro piccoli flussi di traffico e abusi da singoli utenti o indirizzi IP, ma un grande attacco distribuito arriva da molti indirizzi contemporaneamente. La protezione da questi attacchi di solito avviene a livello di rete o CDN, prima che il traffico raggiunga la tua app.