Technik · belegte Antwort
Rate-Limits bei E-Mail-APIs erklärt
Rate-Limiting bei E-Mail-APIs ist ein Mechanismus, mit dem E-Mail-Service-Provider die Zahl der API-Anfragen begrenzen, die ein Nutzer innerhalb eines bestimmten Zeitraums stellen darf. Er verhindert Missbrauch, sorgt für eine faire Verteilung der Ressourcen zwischen Nutzern und schützt die Infrastruktur vor Denial-of-Service-Angriffen, indem er die Aufrufhäufigkeit von Endpunkten wie „E-Mail senden“ oder „Statistiken abrufen“ deckelt.
Technische Umsetzung
Rate-Limits werden meist mit Algorithmen wie Token Bucket oder Leaky Bucket durchgesetzt. Der Provider zählt die Anfragen pro API-Schlüssel oder IP-Adresse. Überschreitet ein Nutzer den festgelegten Schwellenwert, lehnt der Server weitere Anfragen ab, bis das Zeitfenster zurückgesetzt wird. Der Client erfährt das über den HTTP-Statuscode 429 Too Many Requests, oft zusammen mit einem Retry-After-Header, der die Wartezeit in Sekunden angibt.
Bedeutung für Absender
Für Absender ist die Einhaltung von Rate-Limits entscheidend, um den Dienst verfügbar zu halten. Überschreitungen können zur vorübergehenden Sperrung des Kontos oder zur dauerhaften Blockierung von API-Schlüsseln führen. Ein sauberer Umgang damit stellt sicher, dass kritische transaktionale Nachrichten wie Passwort-Zurücksetzungen oder MFA-Codes ohne Unterbrechung zugestellt werden. Außerdem zwingt er Entwickler, effiziente Warteschlangen zu implementieren, statt auf synchrone, stoßweise Traffic-Muster zu setzen.
Fehler im Betrieb
Ein häufiger Fehler ist, im Anwendungscode keinen exponentiellen Backoff zu implementieren. Tritt ein 429-Fehler auf, versuchen naive Systeme es sofort erneut. Das schöpft das Rate-Limit weiter aus und kann Sicherheitsmechanismen auslösen. Ein weiterer Fehler ist, den Unterschied zwischen Limits für gleichzeitige Verbindungen und Limits für Anfragen pro Sekunde zu ignorieren. Das führt zu Timeouts, selbst wenn das stündliche Gesamtkontingent noch nicht erreicht ist.
Implementierungsbeispiel
Ein Entwickler, der eine API für transaktionale E-Mails nutzt, hat beispielsweise ein Limit von 14 Anfragen pro Sekunde. Versucht die Anwendung, 100 E-Mails in einer einzigen Schleife zu senden, sind die ersten 14 erfolgreich, die übrigen 86 schlagen mit 429-Fehlern fehl. Die Lösung: Der Entwickler drosselt die ausgehenden Anfragen mit einer Message Queue wie RabbitMQ oder Redis auf genau 14 pro Sekunde und sorgt so für einen gleichmäßigen Traffic-Fluss.
Tools zur Optimierung
Um die Zustellung zu optimieren und Limits zu vermeiden, können Entwickler mit SendHQ oder den kostenlosen SendHQ-Tools (https://sendhq.cc/tools) ihre Infrastruktur analysieren und sicherstellen, dass ihre Versandmuster den Anforderungen des Providers entsprechen. Wer die Antwort-Header der API überwacht, kann die Versandgeschwindigkeit dynamisch an das in Echtzeit verfügbare Kontingent anpassen.
Häufige Fragen von Teams
Was passiert, wenn ich das Rate-Limit einer E-Mail-API erreiche?
Die API gibt den Fehler HTTP 429 Too Many Requests zurück. Ihre Anfrage wird nicht verarbeitet, und Sie müssen bis zum Ende des Zeitfensters warten, bevor Sie erneut senden.
Wie behandle ich 429-Fehler in meinem Code?
Implementieren Sie exponentiellen Backoff. Das heißt: Nach dem ersten Fehler warten Sie kurz und erhöhen die Wartezeit bei jedem weiteren Fehler exponentiell.
Kann ich meine API-Rate-Limits erhöhen?
Ja. Die meisten Provider erhöhen die Limits abhängig von Kontostufe, Versandhistorie und verifiziertem Volumen. Ein Upgrade auf einen kostenpflichtigen Tarif hebt diese Schwellenwerte in der Regel an.
Ist ein Rate-Limit dasselbe wie ein Versandkontingent?
Nein. Ein Rate-Limit steuert die Geschwindigkeit der Anfragen (z. B. pro Sekunde), ein Versandkontingent das Gesamtvolumen (z. B. pro Monat).
Primärquellen
- Amazon SES Developer Guide – Amazon Web Services
- SendGrid-Dokumentation – Twilio SendGrid
- Resend-Dokumentation – Resend