Limitazione della Frequenza delle API

La limitazione della frequenza è implementata tramite diversi algoritmi, ognuno con diversi compromessi. Finestra Fissa (Fixed Window): conta le richieste per finestra definita (es. 1.000 richieste all'ora). Semplice ma vulnerabile a picchi di traffico ai confini della finestra. Finestra Scorrevole (Sliding Window): una finestra temporale mobile (es. 1.000 richieste in qualsiasi periodo di 60 minuti) elimina i picchi ai confini. Token Bucket: i clienti accumulano "token" a una velocità costante fino a un massimo, e ogni richiesta costa un token. Consente traffico a raffica fino alla dimensione del bucket, pur applicando limiti medi sostenuti — più vicino ai modelli di utilizzo del mondo reale. Leaky Bucket: elabora le richieste a una velocità fissa, mettendo in coda le richieste in eccesso — uniforma completamente il traffico ma introduce latenza durante i picchi. La maggior parte delle piattaforme SaaS utilizza Token Bucket o Sliding Window perché bilanciano la flessibilità per modelli di utilizzo legittimi e a raffica con la protezione contro abusi sostenuti o codice fuori controllo.

Gli errori di limite di frequenza (HTTP 429 "Too Many Requests") sono spesso diagnosticati erroneamente come bug anziché come comportamento API previsto. Il supporto deve: prima verificare che il cliente stia effettivamente superando il limite di frequenza del proprio piano (controllare i dati di utilizzo delle API nella dashboard di amministrazione); istruire sulla risposta 429 e sul suo header retry-after (la risposta API include il tempo fino a quando la prossima richiesta sarà accettata — i client corretti dovrebbero implementare un exponential backoff quando ricevono 429 anziché riprovare immediatamente); indagare se l'implementazione del cliente sta gestendo correttamente i limiti di frequenza (molti bug di integrazione derivano da cicli di retry infiniti che peggiorano il problema del limite di frequenza); determinare se il cliente ha una legittima necessità di un limite di frequenza più elevato (un cliente enterprise il cui caso d'uso richiede un throughput maggiore potrebbe giustificare un limite personalizzato o un upgrade del piano); e documentare sistematicamente le domande sui limiti di frequenza per informare se i limiti a livello di piano sono appropriati o necessitano di aggiustamenti.

I limiti di frequenza sono una decisione di progettazione del prodotto e commerciale, non solo un vincolo tecnico. Product Ops dovrebbe assicurarsi che i limiti di frequenza siano: documentati esplicitamente nella documentazione pubblica delle API (inclusi i limiti per endpoint, non solo i limiti globali); differenziati per livello di prezzo (i clienti con piani superiori ricevono limiti più elevati — questo crea un beneficio concreto e tangibile agli upgrade); visualizzati in tempo reale tramite una dashboard di utilizzo nel prodotto (i clienti dovrebbero essere in grado di vedere il loro consumo attuale rispetto al loro limite, con avvisi prima che raggiungano il limite massimo); e accompagnati da un chiaro percorso di upgrade (un banner o un'email attivata quando un cliente raggiunge l'80% del suo limite di frequenza lo indirizza all'upgrade anziché semplicemente fallire con 429). Gli upgrade guidati dai limiti di frequenza sono un driver misurabile di entrate di espansione che Product Ops traccia insieme ad altri trigger di espansione.