tecnico · risposta con fonti
Rate limiting delle API email: come funziona
Il limite di frequenza (rate limit) delle API email è un meccanismo con cui i provider di servizi email limitano il numero di richieste API che un utente può effettuare in un determinato intervallo di tempo. Previene gli abusi del sistema, garantisce una distribuzione equa delle risorse tra gli utenti e protegge l'infrastruttura dagli attacchi denial of service, limitando la frequenza delle chiamate a endpoint come l'invio di email o il recupero delle statistiche.
Implementazione tecnica
Il limite di frequenza viene applicato di solito con algoritmi come token bucket o leaky bucket. Il provider tiene traccia del numero di richieste per chiave API o indirizzo IP. Quando un utente supera la soglia definita, il server rifiuta le richieste successive finché la finestra temporale non si azzera. Il client viene informato con un codice di risposta HTTP 429 Too Many Requests, spesso accompagnato da un'intestazione Retry After che indica il tempo di attesa in secondi.
Perché conta per chi invia
Per chi invia, rispettare i limiti di frequenza è fondamentale per mantenere la disponibilità del servizio. Superarli può portare alla sospensione temporanea dell'account o al blocco permanente delle chiavi API. Una gestione corretta garantisce che i messaggi transazionali critici, come i reset della password o i codici MFA, vengano consegnati senza interruzioni. Inoltre spinge gli sviluppatori a implementare sistemi di code efficienti invece di affidarsi a traffico sincrono e a raffiche.
Errori operativi
Un errore comune è non implementare il backoff esponenziale nel codice dell'applicazione. Quando si verifica un errore 429, i sistemi più ingenui ritentano subito, esaurendo ulteriormente il limite e rischiando di attivare i controlli di sicurezza. Un altro errore è ignorare la differenza tra i limiti di connessioni concorrenti e i limiti di richieste al secondo, con conseguenti timeout anche quando la quota oraria totale non è stata raggiunta.
Esempio di implementazione
Uno sviluppatore che usa un'API per email transazionali potrebbe avere un limite di 14 richieste al secondo. Se l'applicazione prova a inviare 100 email in un unico ciclo, le prime 14 vanno a buon fine e le restanti 86 falliscono con errori 429. Per risolvere il problema, lo sviluppatore dovrebbe usare una coda di messaggi come RabbitMQ o Redis per limitare le richieste in uscita a esattamente 14 al secondo, garantendo un flusso di traffico costante.
Strumenti di ottimizzazione
Per ottimizzare la consegna ed evitare i limiti, puoi usare SendHQ o i suoi strumenti gratuiti (https://sendhq.cc/tools) per analizzare la tua infrastruttura e assicurarti che i tuoi schemi di invio rispettino i requisiti dei provider. Monitorare le intestazioni delle risposte API consente di regolare dinamicamente la velocità di invio in base alla quota disponibile in tempo reale.
Le domande dei team
Cosa succede quando raggiungo il limite di frequenza di un'API email?
L'API restituisce un errore HTTP 429 Too Many Requests. La richiesta non viene elaborata e devi attendere il periodo di reset prima di riprovare a inviare.
Come gestisco gli errori 429 nel mio codice?
Implementa il backoff esponenziale: attendi un breve periodo dopo il primo errore e aumenta il tempo di attesa in modo esponenziale a ogni errore successivo.
Posso aumentare i limiti di frequenza della mia API?
Sì, la maggior parte dei provider aumenta i limiti in base al livello dell'account, allo storico di invio e ai volumi verificati. Passare a un piano a pagamento di solito alza queste soglie.
Il limite di frequenza è la stessa cosa della quota di invio?
No. Il limite di frequenza controlla la velocità delle richieste (ad es. al secondo), mentre la quota di invio controlla il volume totale (ad es. al mese).
Fonti primarie
- Guida per sviluppatori di Amazon SES — Amazon Web Services
- Documentazione di SendGrid — Twilio SendGrid
- Documentazione di Resend — Resend