Rate Limiting und Throttling
Eine API kann theoretisch jeden Aufruf bedienen – aber Server-Ressourcen sind endlich, Datenbanken haben Grenzen, externe Dienste kosten Geld. Wenn ein Client (absichtlich oder versehentlich) 10.000 Anfragen pro Sekunde schickt, kannst du das nicht ignorieren – sonst geht deine API in die Knie. Hier kommt Rate Limiting ins Spiel: eine Schutzschicht, die festlegt, wie viele Anfragen ein Client innerhalb einer Zeitspanne machen darf.
Diese Lektion erklärt die Mechanik: warum Rate Limiting unverzichtbar ist, welche Algorithmen es gibt (Token Bucket, Leaky Bucket, Fixed/Sliding Window), wie ein Client darauf reagieren soll, welche Header verwendet werden und wie man die Limits sinnvoll setzt. Wer dieses Konzept versteht, schreibt resiliente Clients und entwirft skalierbare Server-APIs.
1) Warum überhaupt Rate Limiting?
Eine API ohne Rate Limit ist wie ein All-you-can-eat-Buffet ohne Türsteher: ein Gast nimmt das ganze Essen mit. Die Konsequenzen ohne Limit sind ernst:
- Server-Überlastung: ein Bot schickt 1000 Anfragen/Sekunde, andere Nutzer warten oder bekommen Timeouts.
- Kosten-Explosion: jede DB-Abfrage, jede Cloud-Funktion kostet. Ein Programmierfehler in einer Schleife kann hohe Cloud-Rechnungen verursachen.
- Brute-Force-Angriffe: Login-Endpunkte ohne Limit erlauben es Angreifern, beliebig viele Passwörter durchzuprobieren. Vgl. K11 Secure Coding.
- Datenscraping: Konkurrenz „saugt" systematisch alle Daten ab.
- DoS-Schutz: bei Denial-of-Service-Angriffen ist Rate Limiting die erste Verteidigungslinie.
Eine schöne Analogie: Türsteher im Club. Er zählt, wer schon drinnen ist. Wenn die Kapazität voll ist, müssen neue Gäste draußen warten. Niemand wird sauer (es gibt Regeln!), aber der Club bleibt funktionsfähig. Genau das macht Rate Limiting.
2) Der Token-Bucket-Algorithmus – live
Der bei weitem populärste Algorithmus heißt Token Bucket. Bild dir vor: jeder Client hat einen Eimer mit Tokens. Jeder API-Aufruf kostet einen Token. Der Eimer wird in regelmäßigen Abständen wieder aufgefüllt – mit einer festen Rate. Ist der Eimer leer, gibt's 429 Too Many Requests. Probier's selbst aus:
3) Die wichtigsten Algorithmen
Rate Limiting kann auf mehrere Arten umgesetzt werden. Jede hat eigene Stärken:
4) Wonach limitieren? – die Granularitäts-Frage
Limits können auf verschiedenen Ebenen festgelegt werden. Je nach Anwendungsfall wählt man:
5) Die richtigen Antworten: Statuscode und Header
Wenn ein Limit überschritten ist, antwortet die API mit 429 Too Many Requests (aus L2). Gute APIs senden dazu Informations-Header, mit denen der Client sein Verhalten anpassen kann:
X-RateLimit-Limit – wie hoch ist das Limit? X-RateLimit-Remaining – wie viele Anfragen sind noch übrig? X-RateLimit-Reset – wann wird zurückgesetzt (Unix-Timestamp)? Retry-After (bei 429) – wie viele Sekunden bis zum nächsten Versuch? Diese Header werden automatisch von Tools wie Postman angezeigt und von Client-Libraries respektiert. Vorsicht: die X--Header sind nicht offiziell standardisiert – manche APIs verwenden ohne X-, andere mit. Das offiziellere wäre RateLimit-* (ohne X). In der Praxis sieht man beide.6) Wie ein guter Client reagiert
Auf einen 429-Fehler darf der Client nicht einfach sofort den nächsten Request schicken. Das macht alles schlimmer – der Server limitiert weiter, der Stack staut sich auf. Bewährte Strategie: Exponential Backoff.
Der Client wartet bei jedem Fehlversuch doppelt so lange wie vorher: 1s, 2s, 4s, 8s, 16s ... Mit jedem Backoff-Schritt fügt man zusätzlich einen kleinen zufälligen Anteil (Jitter) hinzu, damit nicht alle Clients gleichzeitig zur selben Zeit wiederversuchen. So sieht das in Pseudo-Code aus:
async function requestWithRetry(url) { let delay = 1000; // 1 Sekunde for (let i=0; i < 5; i++) { const response = await fetch(url); if (response.status === 429) { const retryAfter = response.headers.get('Retry-After'); const waitTime = retryAfter ? retryAfter * 1000 : delay; const jitter = Math.random() * 500; await sleep(waitTime + jitter); delay *= 2; // Exponential Backoff continue; } return response; } throw new Error('Max Retries reached'); }
Beachte: wenn der Server einen Retry-After-Header schickt, gilt der – sonst eigener Backoff. Nach 5 Versuchen abbrechen, sonst hängst du ewig fest. Reife Client-Libraries wie axios-retry, tenacity (Python) machen das automatisch.
7) Throttling vs. Rate Limiting
Die Begriffe werden oft synonym verwendet, haben aber feine Unterschiede:
- Rate Limiting: harte Grenze. Bei Überschreitung → Anfrage abgewiesen (
429). - Throttling: weichere Form. Bei Überschreitung → Anfrage verlangsamt bearbeitet (Queue, künstliche Verzögerung).
In der Praxis werden beide Begriffe meist gemischt verwendet. In IHK-Klausuren tauchen sie selten als strikte Unterscheidung auf – aber wer den Unterschied erklären kann, zeigt Verständnis.
8) Implementierung: wo läuft das Rate Limiting?
Rate Limiting wird selten in der eigentlichen Anwendung implementiert. Stattdessen sitzt es in Schichten davor:
- API-Gateway / Reverse Proxy: NGINX, Kong, AWS API Gateway, Cloudflare. Sehr verbreitet und performant – das Limit greift, bevor die Anfrage überhaupt das Backend erreicht.
- Middleware im Backend: z.B.
express-rate-limit(Node.js),django-ratelimit(Python),Spring Cloud Gateway. Praktisch, aber Last erreicht das Backend trotzdem. - Service-Mesh: in Microservices-Architekturen z.B. Istio, Linkerd – Limits per Konfiguration ohne Code.
- Datenbank-Layer (Redis): zentrale Zähler in Redis – passend, wenn mehrere Server-Instanzen die Limits teilen müssen.
Klassisch ist die Kombination Gateway + Redis: das Gateway zählt Anfragen pro Key in Redis, prüft das Limit zentral, alle Server-Instanzen sehen denselben Stand.
9) Best Practices und Anti-Patterns
10) Klausurrelevante Punkte
- Warum Rate Limiting? – DoS-Schutz, faire Ressourcen-Verteilung, Brute-Force-Verhinderung, Kosten-Kontrolle.
- Statuscode 429 – „Too Many Requests".
- Header: X-RateLimit-Limit, -Remaining, -Reset, Retry-After.
- Algorithmen: Token Bucket (am häufigsten), Leaky Bucket, Fixed/Sliding Window.
- Granularität: pro IP, pro API-Key, pro User, pro Endpunkt, pro Tier.
- Client-Verhalten: Exponential Backoff mit Jitter, Retry-After respektieren.
Zusammenfassung
Rate Limiting schützt eine API vor Überlastung, Brute-Force-Angriffen, Kostenexplosionen und Daten-Scraping. Analogie: Türsteher im Club. Algorithmen: Token Bucket (Eimer mit Tokens, regelmäßiger Refill, Bursts erlaubt – der häufigste), Leaky Bucket (konstanter Durchsatz), Fixed/Sliding Window. Granularität: pro IP, pro API-Key, pro User, pro Endpunkt (Login streng!), pro Tier (Free/Pro/Enterprise) – oft kombiniert. Bei Überschreitung: 429 Too Many Requests (aus L2). Wichtige Header: X-RateLimit-Limit, -Remaining, -Reset, Retry-After. Bei jeder Antwort senden, nicht nur bei 429. Client-Verhalten: Exponential Backoff mit Jitter (1s, 2s, 4s, 8s + Zufalls-Anteil), Retry-After respektieren. Implementierung: meist in API-Gateway oder Middleware, zentrale Zähler oft in Redis. Klausur-Fokus: Warum-Frage beantworten, Statuscode 429 + Header, Token-Bucket erklären, Backoff-Strategie. Nächste Lektion: API-Testing mit Postman und curl.