Rate Limiting

Rate Limiting beschränkt, wie oft ein Client eine API aufrufen darf, zum Beispiel 100 Anfragen pro Minute und API-Key. Anfragen über dem Limit werden abgelehnt, bis das Zeitfenster zurückgesetzt wird. Das schützt den Dienst vor Überlastung und Missbrauch, verhindert, dass ein einzelner lauter Client andere aushungert, und bremst Angriffe wie das Erraten von Passwörtern. Das Limit wird meist pro API-Key, Nutzer, Token oder IP-Adresse verfolgt.

Beispiel

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30

{"error": "rate_limited", "message": "Try again in 30 seconds"}

429 Too Many Requests und Retry-After sind Standard-HTTP. Header, die das verbleibende Kontingent melden, etwa X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset, sind eine verbreitete Konvention, aber kein einheitlicher Standard. Prüfen Sie daher, was Ihre API dokumentiert.

Gängige Algorithmen

• Fixed Window: Anfragen pro Kalenderminute zählen. Einfach, aber ein Client kann über eine Fenstergrenze hinweg einen doppelten Burst senden.
• Sliding Window: Anfragen über die letzten N Sekunden zählen, was diesen Grenzeffekt glättet.
• Token Bucket: Tokens füllen sich mit konstanter Rate nach, und jede Anfrage verbraucht eines. Das erlaubt kurze Bursts bis zur Größe des Buckets und erzwingt dennoch eine durchschnittliche Rate.

Was Sie testen sollten

• Das Limit selbst: Senden Sie Limit + 1 Anfragen und prüfen Sie, dass genau die zusätzliche Anfrage 429 erhält.
• Erholung: Nach Retry-After oder dem Reset-Zeitpunkt sind Anfragen wieder erfolgreich.
• Geltungsbereich: Der Traffic eines Nutzers oder Keys darf nicht das Kontingent eines anderen aufbrauchen. Prüfen Sie, ob Limits pro Key, pro Nutzer oder pro IP gelten und ob ein Client sie umgehen kann, indem er etwas Billiges rotiert.
• Sensible Endpunkte: Login, Passwort-Reset und OTP-Verifizierung sollten strengere Limits haben als gewöhnliche Lesezugriffe.
• Antwortformat: Eine abgelehnte Anfrage liefert 429 mit einem hilfreichen Body, keinen 500 und keine hängende Verbindung.
• Client-Verhalten: Ihre eigenen Clients ziehen sich zurück (Backoff) und respektieren Retry-After, statt in einer engen Schleife erneut zu versuchen.

Rate Limits und Ihre Testsuite

Parallele API-Tests und Lasttests können produktionsähnliche Limits auslösen und aus Gründen fehlschlagen, die nichts mit der getesteten Änderung zu tun haben. Verwenden Sie in Testumgebungen eigene Keys oder angehobene Limits, und wenn ein Lasttest die Kapazität messen soll, stellen Sie sicher, dass Sie den Dienst messen und nicht den Rate Limiter.