Rate Limiting ist ein Verfahren, das begrenzt, wie viele Requests ein Client, Nutzer, API-Key oder Mandant innerhalb eines Zeitfensters an einen Service senden darf. Requests über dem Limit werden abgewiesen, meist mit HTTP 429 Too Many Requests, oder verzögert. Das schützt Kapazität, sorgt für Fairness zwischen Mandanten und hält Kosten planbar.
Was ist Rate Limiting?
Rate Limiting begrenzt die Zahl der Operationen, die ein Aufrufer pro Zeiteinheit ausführen darf, etwa 100 Requests pro Sekunde und API-Key oder 5 Login-Versuche pro Minute und Konto. Überschreitet ein Aufrufer das Limit, weist der Service weitere Requests ab oder verzögert sie, bis der Aufrufer wieder im Rahmen liegt.
Rate Limits verfolgen mehrere Ziele zugleich: Sie schützen einen Service vor Überlast, verhindern, dass ein Mandant zum Noisy Neighbor wird, bremsen Brute-Force- und Scraping-Angriffe und halten nutzungsbasierte Kosten nachgelagerter APIs im Griff. Rate Limiting ist eine Form der Zugangskontrolle: Es ist besser, einen Teil der Requests schnell abzulehnen, als alle Requests langsam werden zu lassen.
Algorithmen für Rate Limiting
| Algorithmus | Funktionsweise | Abwägung |
|---|---|---|
| Token Bucket | Ein Eimer fasst bis zu b Tokens und wird mit Rate r aufgefüllt. Jeder Request verbraucht ein Token; ist keines übrig, wird abgewiesen. | Erlaubt Bursts bis b bei durchschnittlicher Rate r. Die gängigste Wahl für APIs. |
| Leaky Bucket | Requests landen in einem Eimer, der mit konstanter Rate abfließt. Ist er voll, werden neue Requests verworfen. | Erzeugt eine gleichmäßige Ausgangsrate (Traffic Shaping), fügt aber Wartezeit hinzu und fängt Bursts weniger flexibel ab. |
| Fixed Window Counter | Zählt Requests pro festem Intervall, etwa pro Kalenderminute. | Einfach und günstig, erlaubt an Fenstergrenzen aber bis zum doppelten Limit. |
| Sliding Window Log | Speichert einen Zeitstempel pro Request und zählt die im letzten Intervall. | Exakt, der Speicherbedarf wächst aber mit dem Traffic. |
| Sliding Window Counter | Gewichtet den Zähler des vorigen Fensters mit dem aktuellen. | Gute Näherung bei konstantem Speicher pro Schlüssel. |
In verteilten Systemen liegen die Zähler meist in einem gemeinsamen Speicher wie Redis, oder jede Instanz setzt einen lokalen Anteil des globalen Limits durch. Lokale Limits sind schneller und fallen unabhängig aus, globale Limits sind präziser.
HTTP 429 und Retry-After
Bei HTTP-APIs ist die Standardantwort auf einen Client, der sein Limit überschreitet, 429 Too Many Requests, definiert in RFC 6585. Die Antwort kann einen Retry-After-Header (RFC 9110) enthalten, entweder als Anzahl Sekunden oder als HTTP-Datum, der dem Client sagt, wann er es erneut versuchen darf:
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30
{"error": "rate_limited", "message": "Limit von 100 Requests pro Minute überschritten"}Viele APIs liefern zusätzlich Header mit Limit, verbleibendem Kontingent und Reset-Zeitpunkt, häufig X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset. Diese Namen sind eine Konvention, kein Standard; die IETF-Arbeitsgruppe HTTPAPI arbeitet an standardisierten RateLimit-Headerfeldern. Ist der Service insgesamt überlastet, statt nur einen Client zu begrenzen, antwortet er üblicherweise mit 503 Service Unavailable, ebenfalls optional mit Retry-After.
Rate Limits als Client richtig behandeln
- Retry-After respektieren. Ist der Header gesetzt, warten Sie mindestens so lange.
- Exponentielles Backoff mit Jitter. Zufällige Wartezeiten verhindern, dass alle Clients im selben Moment erneut anfragen und eine neue Spitze erzeugen.
- Retries begrenzen. Kombinieren Sie ein Retry-Budget mit einem Circuit Breaker, damit eine angeschlagene Abhängigkeit nicht weiter belastet wird.
- Vorausschauend drosseln. Nutzen Sie die Header zum Restkontingent, um langsamer zu werden, bevor das Limit greift.
Rate Limiting überwachen
Rate Limiting nützt nur, wenn Sie sehen, dass es wirkt. Messen Sie die Zahl gedrosselter Requests pro Client, Route und Limit, den Anteil der 429-Antworten an Ihrer gesamten Fehlerrate und wie nah die größten Verbraucher an ihren Limits liegen. Entscheiden Sie bewusst, ob 429-Antworten in Ihr SLO einfließen: Abweisungen, weil ein Client seinen Vertrag überschreitet, zählen meist nicht; Abweisungen, weil Limits für normalen Traffic zu niedrig sind, schon. Ein plötzlicher Anstieg von 429ern nach einem Deployment deutet oft auf ein falsch konfiguriertes Limit oder einen Retry-Sturm eines Clients hin.
Typische Fehler
- Limits ohne Datengrundlage: Messen Sie den realen Traffic pro Client und dessen Spitzen, bevor Sie Werte festlegen.
- Limits nur nach IP-Adresse, was Nutzer hinter gemeinsamem NAT bestraft und sich mit vielen IPs leicht umgehen lässt.
- 500 oder 503 statt 429 zurückgeben, sodass Clients Drosselung nicht von Fehlern unterscheiden können.
- Rate Limiting nur am Edge, während teure interne Endpunkte ungeschützt bleiben.
- Limits ändern, ohne die betroffenen API-Nutzer vorher zu informieren. Dokumentieren Sie Limits öffentlich und kündigen Sie Änderungen an.
Wie Obseria hilft
Obseria erfasst HTTP-Statuscodes und Attribute wie Route und Client auf jedem Span. So können Sie 429-Antworten pro API-Key oder Mandant auswerten und im Distributed Tracing sehen, wo gedrosselt wurde. Die Anomalieerkennung hebt ungewöhnliche Spitzen bei gedrosselten Requests hervor, und Metriken von Gateways und Proxys, etwa aus NGINX, zeigen Limit-Treffer am Edge.
