Rate Limiting

Jedes System hat eine Kapazitätsgrenze. Die Frage ist, was passiert, wenn mehr Anfragen kommen, als es verarbeiten kann – sei es durch einen Ansturm echter Nutzer, einen fehlerhaften Client in einer Endlosschleife, einen Scraper oder einen Angriff. Ohne Schutz wird das System für alle langsam oder fällt aus. Rate Limiting begrenzt deshalb, wie viele Anfragen ein Client in einem Zeitraum stellen darf. Es ist eine der einfachsten und wirksamsten Maßnahmen für stabile Systeme und gehört in jede öffentliche Schnittstelle.

1. Warum begrenzen?

Rate Limiting verfolgt mehrere Ziele. Es schützt das System vor Überlastung durch einzelne Clients. Es sorgt für Fairness, damit ein einzelner Nutzer nicht die Kapazität aller anderen verbraucht. Es kontrolliert Kosten, was bei KI-Anwendungen besonders wichtig ist, weil jede Anfrage an ein Sprachmodell Geld kostet. Und es erschwert Missbrauch, etwa das massenhafte Durchprobieren von Passwörtern, das Abgreifen von Inhalten oder das Versenden von Spam über Kontaktformulare.

2. Verfahren

Das einfachste Verfahren ist das feste Fenster: Pro Minute sind hundert Anfragen erlaubt, zu Beginn jeder Minute wird der Zähler zurückgesetzt. Es ist leicht umzusetzen, hat aber eine Schwäche: An der Grenze zwischen zwei Minuten können doppelt so viele Anfragen durchkommen, hundert am Ende der einen und hundert am Anfang der nächsten. Das gleitende Fenster betrachtet stattdessen immer die letzten sechzig Sekunden und vermeidet diesen Effekt. Der Token Bucket schließlich ist das flexibelste und verbreitetste Verfahren: Ein Eimer enthält Token, die sich mit fester Rate auffüllen; jede Anfrage verbraucht ein Token, und ist der Eimer leer, wird abgelehnt. So sind kurze Spitzen bis zur Eimergröße erlaubt, während die Dauerrate begrenzt bleibt.

3. Wonach begrenzen?

Eine wichtige Entscheidung ist, wonach begrenzt wird. Die IP-Adresse ist für anonyme Anfragen oft das einzige Merkmal, aber ungenau: Hinter einer IP können viele Nutzer eines Unternehmens oder eines Mobilfunknetzes stehen, während Angreifer viele IP-Adressen nutzen. Das Nutzerkonto oder der API-Schlüssel sind genauer und erlauben unterschiedliche Grenzen je nach Tarif. Bei mandantenfähigen Systemen kommt die Begrenzung pro Mandant hinzu, damit ein großer Kunde nicht alle anderen ausbremst. Häufig werden mehrere Ebenen kombiniert, und besonders sensible Endpunkte wie Login, Passwort-Zurücksetzen oder teure KI-Funktionen erhalten eigene, strengere Grenzen.

Für KI-Anwendungen reicht die Zahl der Anfragen oft nicht als Maß. Eine Anfrage mit einem kurzen Satz kostet wenig, eine mit einem langen Dokument viel. Deshalb begrenzt man hier zusätzlich nach verbrauchten Token oder nach Kosten, etwa mit einem Tagesbudget pro Nutzer. Die Anbieter von Sprachmodellen tun übrigens dasselbe gegenüber ihren Kunden, sodass eine Anwendung auch deren Grenzen einplanen muss.

4. Wo begrenzen?

Rate Limiting kann an verschiedenen Stellen stattfinden. Am Rand, im CDN oder in einer Web Application Firewall, lassen sich grobe Angriffe abwehren, bevor sie den eigenen Server erreichen. Im API-Gateway oder Load Balancer werden Grenzen für alle Dienste einheitlich durchgesetzt. In der Anwendung selbst sind die genauesten Grenzen möglich, weil dort Nutzer, Tarif und Art der Operation bekannt sind. Bei mehreren Instanzen muss der Zähler gemeinsam geführt werden, meist in Redis, weil sonst jede Instanz ihr eigenes Limit hätte und die tatsächliche Grenze mit der Zahl der Instanzen wächst. Atomare Operationen in Redis oder fertige Bibliotheken nehmen einem die Details ab.

5. Gut kommunizieren

Ein Rate Limit ist Teil der Schnittstelle und sollte verständlich sein. Die Antwort bei Überschreitung ist HTTP 429 mit einem Header Retry-After, der angibt, wann ein neuer Versuch sinnvoll ist. Viele Schnittstellen senden zusätzlich bei jeder Antwort Header mit dem Limit, den verbleibenden Anfragen und dem Zeitpunkt der Zurücksetzung, sodass Clients ihre Anfragen einteilen können. In der Dokumentation werden die Grenzen offen genannt. Und in der Benutzeroberfläche erscheint eine freundliche Meldung statt einer kryptischen Fehlermeldung – etwa „Sie haben das Tageskontingent für KI-Zusammenfassungen erreicht. Es wird um Mitternacht zurückgesetzt.“

6. Rate Limiting und Lastabwurf

Rate Limiting schützt vor einzelnen Clients, aber nicht unbedingt vor einer Gesamtüberlastung, wenn sehr viele Clients jeweils innerhalb ihrer Grenzen bleiben. Dafür gibt es den Lastabwurf, im Englischen Load Shedding: Ist das System insgesamt überlastet, lehnt es gezielt weniger wichtige Anfragen ab, um die wichtigen zu bedienen. Ein Onlineshop kann bei Überlast etwa Empfehlungen und Suchvorschläge abschalten, damit Warenkorb und Bezahlung weiter funktionieren. Zusammen mit den Werkzeugen der vorigen Lektion – Zeitlimits, Backoff und Circuit Breaker – bildet Rate Limiting damit den Abschluss dieses Moduls: Ein skalierbares System kann nicht nur wachsen, sondern weiß auch, wie es sich verhält, wenn seine Grenzen erreicht sind. Das folgende Modul vertieft diesen Gedanken mit Verfügbarkeit, Redundanz und Überwachung.

7. Ein Beispiel

Ein Yogastudio bietet eine App mit Kursbuchung und einem KI-Assistenten an, der Fragen zu Übungen beantwortet. Der Entwurf sieht mehrere Grenzen vor. Der Login erlaubt pro Konto fünf Fehlversuche in fünfzehn Minuten und pro IP-Adresse fünfzig, um Passwortangriffe zu bremsen. Die Buchungsschnittstelle erlaubt pro Nutzer dreißig Anfragen pro Minute, was für normale Nutzung weit mehr als genug ist, aber fehlerhafte Clients stoppt. Der KI-Assistent hat ein Tageskontingent von zwanzig Fragen pro Mitglied und ein Gesamtbudget pro Tag, bei dessen Erreichen er freundlich auf den nächsten Tag verweist. Die Zähler liegen in Redis, damit alle Instanzen dieselben Grenzen durchsetzen.

Als kurz vor Jahresbeginn eine Aktion für neue Mitgliedschaften startet, steigt die Last deutlich. Die Grenzen sorgen dafür, dass ein fehlerhaft programmiertes Skript eines Partners, das die Kursliste im Sekundentakt abruft, nach wenigen Sekunden gebremst wird, statt die Datenbank zu belasten. Gleichzeitig bemerken echte Mitglieder nichts von den Grenzen, weil sie großzügig bemessen sind. Genau so soll Rate Limiting wirken: unsichtbar für normale Nutzung, wirksam gegen Ausreißer und Missbrauch. Die Grenzwerte werden anhand der gemessenen Nutzung regelmäßig überprüft und angepasst, damit sie weder zu streng noch zu großzügig werden.

Rate Limiting ist damit weniger eine Frage der Technik als eine der bewussten Entscheidung: Was ist knapp, was ist teuer, was muss geschützt werden? Wer diese Fragen beantwortet, findet passende Grenzen und schützt das System, ohne die eigenen Nutzer zu verärgern.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.