Jede API, die für andere Systeme oder Nutzer offen ist, braucht eine Grenze. Ohne sie kann ein einzelner fehlerhafter Client in einer Endlosschleife, ein aggressiver Crawler oder ein gezielter Angriff die Ressourcen so belasten, dass für alle anderen nichts mehr übrig bleibt. Rate Limiting ist die kontrollierte Drosselung: Es legt fest, wie viele Anfragen ein Client in einem Zeitfenster stellen darf — und schützt so Stabilität, Kosten und Fairness.
Warum Rate Limiting kein Nice-to-have ist
Drei Probleme löst es gleichzeitig. Es verhindert Überlast, indem es Lastspitzen abfängt, bevor sie die Datenbank oder nachgelagerte Dienste erreichen. Es begrenzt Missbrauch, etwa das massenhafte Abgreifen von Daten oder Brute-Force-Versuche an Login-Endpunkten. Und es steuert Kosten, weil bei Cloud-Diensten und bezahlten Fremd-APIs jede Anfrage Geld kostet.
Die wichtigsten Algorithmen
Fixed Window: Zählt Anfragen pro festem Zeitfenster, etwa 100 pro Minute. Einfach, aber am Fensterrand entstehen Doppelspitzen — kurz vor und nach dem Wechsel können sich Anfragen häufen.
Sliding Window: Ein gleitendes Fenster glättet diese Ränder, indem es die letzten 60 Sekunden ab jetzt betrachtet statt starrer Blöcke. Fairer, etwas aufwendiger.
Token Bucket: Ein Eimer füllt sich stetig mit Tokens, jede Anfrage verbraucht einen. Ist der Eimer leer, wird gedrosselt. Erlaubt kurze Bursts, solange im Schnitt das Limit hält — der praktische Standard für viele APIs.
Leaky Bucket: Anfragen laufen mit konstanter Rate ab, wie Wasser durch ein Loch. Glättet den Durchsatz besonders gleichmäßig, dafür weniger tolerant gegenüber Bursts.
Token Bucket ist für die meisten Anwendungen der beste Kompromiss: Es lässt legitime Lastspitzen zu und drosselt trotzdem dauerhaften Missbrauch.
Limits fair gestalten
Ein zu strenges Limit sperrt echte Nutzer aus, ein zu großzügiges schützt nicht. Der Schlüssel ist Differenzierung. Staffeln Sie Limits nach Client-Typ: anonyme Anfragen niedriger, authentifizierte höher, zahlende Kunden am höchsten. Trennen Sie teure von billigen Endpunkten — eine Suche oder ein Report darf ein engeres Limit haben als ein simpler Statusabruf.
Sauber kommunizieren
Ein gedrosselter Client muss verstehen, was passiert. Der Standard dafür ist der HTTP-Status 429 Too Many Requests, ergänzt um aussagekräftige Header:
- Retry-After: nach wie vielen Sekunden ein neuer Versuch sinnvoll ist
- X-RateLimit-Limit: das erlaubte Kontingent im Fenster
- X-RateLimit-Remaining: wie viele Anfragen noch offen sind
So kann ein gut gebauter Client seine Anfragen selbst bremsen, statt blind gegen die Wand zu laufen.
Wo das Limit greifen sollte
Am wirkungsvollsten ist Rate Limiting so weit außen wie möglich — am API-Gateway oder Reverse Proxy, bevor die Anfrage teure Ressourcen erreicht. In verteilten Systemen mit mehreren Instanzen braucht der Zähler einen gemeinsamen Speicher wie einen zentralen In-Memory-Store, sonst zählt jede Instanz für sich und das Limit ist faktisch vervielfacht.
Throttling vs. hartes Ablehnen
Nicht jede Grenze muss zur harten Ablehnung führen. Zwei Reaktionen sind üblich: Beim harten Limit wird jede Anfrage über der Grenze mit 429 abgewiesen. Beim Throttling werden Anfragen stattdessen verzögert verarbeitet, sodass der Client langsamer, aber weiter bedient wird. Für interne Dienste ist Verzögerung oft freundlicher, für öffentliche Endpunkte und Missbrauchsschutz ist die klare Ablehnung meist sinnvoller. Welche Reaktion passt, hängt davon ab, ob der Client legitim, aber zu schnell ist — oder schlicht schädlich.
Rate Limiting ist kein Ersatz für Sicherheit
Eine Drosselung bremst Missbrauch, ersetzt aber keine Authentifizierung, keine Eingabevalidierung und keinen echten DDoS-Schutz auf Netzwerkebene. Ein verteilter Angriff aus tausenden Quellen umgeht ein pro-Client-Limit, weil jede einzelne Quelle unter der Grenze bleibt. Rate Limiting ist deshalb eine Schicht in einem gestaffelten Schutzkonzept — wirksam gegen einzelne aggressive Clients und versehentliche Überlast, aber immer kombiniert mit Authentifizierung und, bei Bedarf, vorgelagertem Schutz durch das Gateway oder einen spezialisierten Dienst.
Rate Limiting ist eine der günstigsten Absicherungen mit der größten Wirkung. Es kostet wenig, verhindert aber Ausfälle, Kostenexplosionen und Missbrauch — und sorgt dafür, dass Ihre API auch dann verfügbar bleibt, wenn ein einzelner Client sich danebenbenimmt.