Rate Limiting für APIs: Algorithmen, Limits und Wiederholversuche

Die beste Strategie für Rate Limiting ist bei den meisten APIs ein Token Bucket (oder ein Sliding-Window-Zähler) pro authentifizierter Client-Identität, kombiniert mit einem strengeren Limit für teure Endpunkte, einer klaren Antwort 429 Too Many Requests samt Retry-After-Header und einem gemeinsamen Speicher wie Redis, sobald Sie mehr als eine Instanz betreiben. Alles Weitere ist Feinabstimmung. Dieser Leitfaden zeigt, wie Sie die einzelnen Bausteine wählen, wo die Kompromisse liegen und wie sich die Client-Seite verhalten sollte, wenn sie an ein Limit stösst.

Kurz zusammengefasst

• Rate Limiting begrenzt, wie viele Anfragen ein Client in einem Zeitfenster stellen darf. Das schützt vor Überlastung, unfairer Nutzung, Missbrauch und ausufernden Kosten.
• Wählen Sie den Algorithmus nach dem Verkehrsmuster: Token Bucket für legitime Lastspitzen, Leaky Bucket zum Glätten des Verkehrs vor empfindlichen Systemen, Sliding Window, wenn Spitzen an Fenstergrenzen stören, Fixed Window, wenn Einfachheit zählt.
• Begrenzen Sie nach der Identität, die zu Ihrem Risiko passt: API-Schlüssel oder Benutzer:in bei zahlenden Kundschaften, IP bei anonymem Verkehr, Mandant für Fairness in Multi-Tenant-Systemen und Endpunkt bei teuren Operationen.
• Antworten Sie mit 429 und Retry-After, veröffentlichen Sie Ihre Limits und erwarten Sie von Clients Wiederholversuche mit exponentiellem Backoff und Jitter.
• Bei mehreren Instanzen entscheiden Sie, wie exakt das globale Limit sein muss. Exaktheit kostet Latenz und schafft eine gemeinsame Abhängigkeit.

Was Rate Limiting leistet und warum Sie es brauchen

Rate Limiting regelt, wie viele Anfragen eine Person in einer bestimmten Zeit stellen darf. Microsoft’s documentation nennt als Nutzen: Überlastung verhindern, faire Nutzung sicherstellen, Sicherheit erhöhen und Kosten steuern. Diese vier Gründe münden später in konkrete Entscheidungen, deshalb lohnt es sich, sie auseinanderzuhalten.

Überlastung. Ein einziges fehlerhaftes Skript, ein Bug in einer Retry-Schleife eines Clients oder ein viraler Start kann mehr Verkehr erzeugen, als Ihre Datenbank bedienen kann. Ein Limit hält den Schaden bei der Aufruferin, die ihn verursacht hat.

Fairness. Ohne Limits kann eine einzelne lastintensive Kundschaft die gemeinsame Kapazität für sich beanspruchen. Akamai beschreibt das Ziel so: berechtigten Nutzer:innen eine ähnliche Servicequalität bieten und preventing resource monopolization, bei gleichzeitiger Beobachtung der Nutzung, um Probleme zu erkennen.

Sicherheit. Endpunkte für Anmeldung, Passwort-Zurücksetzung und Tokens ziehen Brute-Force-Versuche an. Ein striktes Limit auf diesen Routen ist eine der günstigsten Schutzmassnahmen überhaupt.

Kosten. Wenn eine Anfrage aufwendige Berechnungen, grosse Datenbankabfragen oder einen kostenpflichtigen Aufruf bei Dritten auslöst, kostet jede zusätzliche Anfrage Geld. Limits machen aus einer offenen Rechnung eine begrenzte. Besonders wichtig ist das, wenn Ihre API vor anderen APIs steht: Versanddienstleister, Zahlungsanbieter und KI-Modelle setzen eigene Limits durch, und Ihr Dienst muss diese einhalten. Wenn Sie mit APIs von Versanddienstleistern arbeiten, zeigt diese Übersicht zu shipping API integration pitfalls, wie schnell solche Vorgaben ein Projekt prägen.

Das Thema hat auch eine menschliche Seite. Der Katalog API Patterns hält fest, dass ein Entwurf für Rate Limits economics, performance, reliability, abuse severity and client awareness abwägen sollte. Klare Limits gehören zum API-Vertrag, damit Ihre Clients ihr Tempo anpassen, Arbeit bündeln und Antworten zwischenspeichern können.

Rate Limiting und Throttling

Die beiden Begriffe werden oft synonym verwendet, und Anbieter definieren sie leicht unterschiedlich. Am nützlichsten ist eine Unterscheidung danach, was mit der überzähligen Anfrage geschieht.

• Rate Limiting setzt eine harte Obergrenze, zum Beispiel 100 Anfragen pro Minute, und weist alles darüber zurück. So beschreibt es auch Gravitee’s explanation.
• Throttling formt den Verkehr. Je nach Last und Regelwerk verzögert, reiht oder verwirft es Anfragen. Zuplo bringt es auf den Punkt: Ein Limiter weist ab, ein Throttle reiht Anfragen ein und führt sie aus, sobald Kapazität frei ist.

Nicht alle ziehen die Grenze an derselben Stelle. Rokka, ein Schweizer Bilddienst, beschreibt sein throttling as delaying requests, bevor überzählige Aufrufe mit einem 429 abgewiesen werden. In der Praxis ist Throttling eine Familie von Verhaltensweisen und Rate Limiting eine davon.

Aus Sicht des Clients gibt es eine einfache Faustregel zur Unterscheidung. Laut Requestly deutet steigende Latenz bei erfolgreichen 2xx-Antworten auf Throttling hin, während sofortige 429-Antworten bedeuten, dass eine harte Grenze erreicht wurde.

Ein verwandter Begriff ist das Kontingent. Rate Limits gelten meist für kurze Intervalle wie Sekunden, Minuten oder Stunden, während Zuplo wie Tage, Wochen oder Monate. Die meisten kommerziellen APIs nutzen beides: ein Limit pro Minute zum Schutz des Systems und ein monatliches Kontingent passend zum Abo.

Die wichtigsten Algorithmen

Vier Algorithmen decken fast jeden Produktivfall ab. Vercel’s comparison nennt Fixed Window, Sliding Window (Log oder Zähler), Token Bucket und Leaky Bucket.

Algorithmus	Funktionsweise	Stärke	Schwäche	Passt am besten zu
Fixed Window	Zählt Anfragen in festen Intervallen, etwa pro Minute	Günstig und einfach	Spitzen an den Fenstergrenzen	Interne Werkzeuge, grober Schutz
Sliding Window Log	Speichert einen Zeitstempel pro Anfrage	Exakt	Hoher Speicherbedarf	Geringes Volumen, hohe Präzision
Sliding Window Counter	Gewichtet die Zählerstände des aktuellen und des vorherigen Fensters	Fester Speicherbedarf	Nur annähernd genau	Allgemeine öffentliche APIs
Token Bucket	Tokens füllen sich in gleichmässigem Tempo nach, jede Anfrage verbraucht eines	Erlaubt kontrollierte Lastspitzen	Benötigt Berechnung des Nachfüllens	Entwickler-APIs mit legitimen Lastspitzen
Leaky Bucket	Anfragen landen in einer Warteschlange, die mit konstanter Rate abfliesst	Gleichmässige Ausgabe	Durch die Warteschlangengrösse begrenzt, erzeugt Verzögerung	Schutz empfindlicher nachgelagerter Systeme

Die Kompromisse ähneln sich über alle Quellen hinweg. Upstash’s documentation beschreibt Fixed Windows als günstig, aber anfällig für Spitzen an den Fenstergrenzen, Sliding Windows als Lösung dieses Problems zum Preis von mehr Speicher und Rechenaufwand und Token Buckets als Weg, kontrollierte Spitzen zuzulassen, allerdings mit laufender Berechnung des Nachfüllens.

Das Problem der Spitzen an Fenstergrenzen

Bei einem festen Fenster von 100 Anfragen pro Minute kann ein Client um 12:00:59 hundert Anfragen senden und um 12:01:00 nochmals hundert. Das sind 200 Anfragen in zwei Sekunden, obwohl jedes Fenster formal innerhalb seines Limits bleibt. Wenn Ihr Backend die doppelte Nennrate nicht verkraftet, wechseln Sie zu einem Sliding Window oder einem Token Bucket.

Token Bucket einfach erklärt

Stellen Sie sich einen Eimer mit 20 Tokens vor, der sich mit 5 Tokens pro Sekunde füllt. Ein Client, der eine Weile untätig war, kann 20 Anfragen auf einmal senden und pendelt sich danach bei 5 pro Sekunde ein. Genau so verhalten sich echte Integrationen: Ein Seitenaufruf löst mehrere Aufrufe gleichzeitig aus, danach wird es still. Vercel empfiehlt Token Buckets für Vercel’s comparison und Leaky Buckets, um den Verkehr vor empfindlichen nachgelagerten Abhängigkeiten zu glätten.

Eine praxistaugliche Grundeinstellung

Wenn kein triftiger Grund dagegen spricht, beginnen Sie mit einem Token Bucket oder einem Sliding-Window-Zähler. Beide vermeiden das Grenzproblem ohne den Speicherbedarf eines vollständigen Logs. Einen Leaky Bucket setzen Sie nur ein, wenn ein System hinter Ihrer API wirklich eine konstante Anfragerate braucht.

Wonach Sie begrenzen

Der Algorithmus bestimmt, wie gezählt wird. Der Schlüssel bestimmt, wer gezählt wird. MDN weist darauf hin, dass Limits serverweit oder pro Ressource gelten können und typischerweise auf der IP-Adresse eines Clients beruhen oder, bei authentifizierten Anfragen, auf users or authorized applications.

Schlüssel	Einsetzen, wenn	Achten Sie auf
IP-Adresse	Anonymer Verkehr, Anmeldeseiten, öffentliche Endpunkte	Viele Nutzer:innen hinter einer Büro- oder Mobilfunkadresse
API-Schlüssel oder Benutzer:in	Authentifizierte APIs und kostenpflichtige Abos	Abhandengekommene Schlüssel, massenhaft angelegte Gratis-Konten
Mandant oder Organisation	Multi-Tenant-Produkte, bei denen Fairness zwischen Kundschaften zählt	Viele Nutzer:innen eines Mandanten teilen sich ein Budget
Endpunkt	Teure oder sensible Routen	Zu viele einzelne Regeln, die gepflegt werden müssen

Die meisten ausgereiften APIs kombinieren diese Schlüssel. Ein häufiges Muster ist ein grosszügiges Limit pro Schlüssel über die ganze API hinweg, ergänzt um deutlich strengere Limits für einzelne Endpunkte. Salesforce beschreibt zum Beispiel den Einsatz von per-tenant, per-endpoint limits im eigenen koordinierten Limiter.

Die Zahlen festlegen

Keine Formel liefert Ihnen den richtigen Wert. Ein gangbarer Weg sieht so aus:

1. Echten Verkehr messen. Ermitteln Sie die typischen und die Spitzenraten Ihrer gut funktionierenden Clients pro Schlüssel.
2. Kapazität bestimmen. Testen Sie die langsamste Abhängigkeit unter Last (meist die Datenbank), um zu sehen, wie viele Anfragen sie bedienen kann, bevor die Latenz leidet.
3. Das Limit über die normalen Spitzen setzen, aber deutlich unter die Kapazität geteilt durch die Zahl der Clients, die voraussichtlich gleichzeitig aktiv sind.
4. Nach Wert abstufen. Geben Sie zahlenden Abos höhere Limits und teuren Endpunkten eigene, niedrigere.
5. Im Beobachtungsmodus starten. Protokollieren Sie, was blockiert worden wäre, bevor Sie etwas durchsetzen.

Der letzte Schritt ist entscheidend. Akamai warnt, dass zu aggressiv tiefe oder uneinheitliche Limits bei legitimen Nutzer:innen zu preventing resource monopolization führen können. Ein Limit, das eine gute Kundschaft während einer normalen Stosszeit blockiert, ist ein Fehler und kein Schutz.

Limits über mehrere Instanzen hinweg durchsetzen

Ein Limiter, der in einem einzelnen Prozess zählt, ist einfach. Schwierig wird es, wenn Ihre API auf mehreren Instanzen oder in mehreren Regionen läuft, denn jede sieht nur einen Teil des Verkehrs.

Tyk beschreibt das Kernproblem: Wenn jede Data Plane die Limits für sich durchsetzt, the effective global limit can multiply. Aus einem Limit von 100 pro Minute werden über fünf Instanzen unbemerkt 500.

Sie haben drei grundsätzliche Möglichkeiten:

• Lokale Zähler pro Instanz. Am schnellsten und am stärksten isoliert, aber das globale Limit ist nur ungefähr.
• Ein gemeinsamer Redis-Speicher. Exakte Abstimmung, doch jede Anfrage zahlt einen Netzwerk-Roundtrip, und der Speicher wird zur Abhängigkeit, deren Ausfall jede Anfrage betrifft. Tyk benennt beide Kosten.
• Repliziertes Redis. Bessere Verfügbarkeit, aber nur letztlich konsistent, sodass Limits während der Replikationsverzögerung überschritten werden können.

Die Empfehlung von the effective global limit can multiply lautet, den Entwurf an der benötigten Konsistenz auszurichten: Durchsetzung pro Region begünstigt Latenz und Isolation, exakte globale Limits verlangen gemeinsame Abstimmung und nehmen deren Kosten bei Verfügbarkeit und Latenz in Kauf.

Reale Systeme nehmen oft eine kleine Ungenauigkeit in Kauf. Salesforce kombiniert lokale und Redis-gestützte Caches mit atomaren Redis-Inkrementen und per-tenant, per-endpoint limits. GitHub berichtet in weit grösserem Massstab vom Einsatz eines geshardeten Redis mit Primärknoten für Schreibvorgänge und Replikaten für Lesevorgänge, dazu Redis-Ablaufzeiten und Lua scripts to keep rate-limit operations atomic.

Daraus folgen zwei praktische Regeln:

• Machen Sie die Prüfung atomar. Ein Lesevorgang mit anschliessendem separatem Schreibvorgang lässt zwei gleichzeitige Anfragen beide durch. Verwenden Sie ein einzelnes atomares Inkrement oder ein Skript.
• Legen Sie fest, was bei Ausfall des Speichers passiert. Offen scheitern hält die API verfügbar, aber ungeschützt. Geschlossen scheitern schützt das Backend, blockiert aber alle. Für die meisten öffentlichen APIs ist offen scheitern mit einem zurückhaltenden lokalen Ersatzlimit ein sinnvoller Mittelweg. Bei Anmeldeendpunkten kann die umgekehrte Wahl richtig sein.

Auch der Ort der Durchsetzung zählt. Ein API-Gateway oder eine Edge-Schicht stoppt überzähligen Verkehr, bevor er Ihre Anwendung erreicht, und Limits auf Anwendungsebene regeln danach die fachlichen Vorgaben wie Kontingente pro Abo.

Was Sie zurückgeben, wenn ein Client das Limit erreicht

Die Standardantwort ist HTTP 429. MDN erklärt, dass eine API mit users or authorized applications antworten kann, der dem Client mitteilt, wie lange er bis zum nächsten Versuch warten soll.

Gute Antworten auf ein erreichtes Limit haben einige Gemeinsamkeiten:

• Ein Status 429, kein allgemeiner 500 und kein 403.
• Ein Retry-After-Header mit der Wartezeit.
• Limit-Header auf normalen Antworten, die das Limit und den verbleibenden Rest zeigen, damit Clients langsamer werden, bevor sie blockiert werden. Die API von Rokka liefert zum Beispiel throttling as delaying requests auf den Endpunkten zur Cache-Invalidierung und einen Retry-After-Header bei 429.
• Ein kurzer, verständlicher Fehlertext, der das erreichte Limit benennt und auf Ihre Dokumentation verweist.

Veröffentlichen Sie die Limits in Ihrer Dokumentation. Überraschende Limits erzeugen Support-Anfragen, gut dokumentierte erlauben es Integrator:innen, von Anfang an damit zu planen.

Wie Clients reagieren sollten: Backoff und Jitter

Ein Limit wirkt nur, wenn sich die Clients vernünftig verhalten. Üblich sind Wiederholversuche mit exponentiellem Backoff, also mit nach jedem Fehlschlag längerer Wartezeit. Jitter, eine zufällige Schwankung der Wartezeit, verhindert, dass viele Clients im selben Moment erneut anfragen.

Das ist gängige Empfehlung der grossen Cloud-Anbieter. AWS SDKs können Anfragen, die an vorübergehenden Fehlern oder an Throttling scheitern, automatisch wiederholen, und zwar mit exponentiellem Backoff und Jitter. Google Cloud recommends dasselbe Muster für vorübergehende Fehler wie HTTP 429 und 5xx. Google rät zudem zu truncated exponential backoff with jitter, um gleichzeitige Wiederholversuche zu verhindern, den sogenannten Thundering Herd.

Ein solider Client tut Folgendes:

1. Retry-After beachten, wenn vorhanden, und sonst auf exponentielles Backoff zurückfallen.
2. Jeder Wartezeit zufälligen Jitter hinzufügen.
3. Maximale Wartezeit und Anzahl Versuche begrenzen.
4. Nur sichere oder idempotente Anfragen wiederholen oder einen Idempotenzschlüssel mitsenden.
5. Antworten zwischenspeichern und Aufrufe bündeln, damit von vornherein weniger Anfragen nötig sind.

Wiederholversuche sind nicht immer die Lösung. Bei Googles Provisioned Throughput bedeuten häufige 429-Fehler meist, dass die Google Cloud recommends, weitere Wiederholversuche beheben das zugrunde liegende Problem also nicht. Wenn Sie auf einer bezahlten, reservierten Stufe dauernd 429 sehen, hilft nur mehr Kapazität oder weniger Aufrufe. Beachten Sie auch, dass AWS das Abschalten von Wiederholversuchen erlaubt, indem man die AWS SDKs vornimmt. Das ist nützlich, wenn ein Fehler sofort sichtbar werden statt verdeckt bleiben soll.

Checkliste bewährter Vorgehensweisen

Diese Liste fügt die Bausteine zusammen:

• Zuerst den Verkehr analysieren. Wissen Sie, wie normal aussieht, bevor Sie Zahlen festlegen.
• Den Algorithmus zum Verkehr passend wählen. Stossweiser Entwickler-Verkehr verlangt einen Token Bucket. Empfindliche Backends verlangen einen Leaky Bucket.
• Schlüssel schichten. Ein globales Limit pro Client plus strengere Limits pro Endpunkt deckt die meisten Risiken ab.
• Sensible Routen stärker schützen. Anmeldung, Passwort-Zurücksetzung und teure Operationen verdienen eigene, niedrigere Limits.
• Fairness in Multi-Tenant-Systemen wahren. Begrenzen Sie pro Mandant, damit eine Kundschaft nicht die Kapazität aller aufbraucht.
• Kommunizieren. Nutzen Sie 429, Retry-After und Limit-Header und dokumentieren Sie alles.
• Überwachen. Verfolgen Sie blockierte Anfragen pro Schlüssel und pro Endpunkt. Ein Anstieg der Blockaden bei einer legitimen Kundschaft heisst meist, dass Ihr Limit falsch ist, und nicht, dass sie Sie angreift.
• Regelmässig überprüfen. Der Verkehr wächst, Funktionen ändern sich, und ein vor einem Jahr gewähltes Limit kann heute zu eng oder zu weit sein.
• Den Limiter nach Möglichkeit vom kritischen Pfad fernhalten. Nutzen Sie lokale Caches und akzeptieren Sie geringe Überschreitungen, wenn Exaktheit die Latenz nicht wert ist.

So bringen Sie das in Ihr Produkt

Rate Limiting betrifft das Gateway, die Anwendung, den Datenspeicher und die Dokumentation für Clients. Es gelingt darum leichter, wenn ein erfahrenes Team das Gesamtbild verantwortet. Bei Ampersand, einem Studio in Zürich, führen erfahrene Entwickler:innen jedes Projekt von der ersten Beratung bis zur Übergabe, und wir bauen und verbinden APIs, Webanwendungen und Plattformen für Startups und wachsende Teams. Wenn Sie Unterstützung brauchen, um Limits für eine neue Plattform zu entwerfen, Systeme mit streng kontingentierten APIs zu verbinden oder eine Integration nach dem Start gesund zu halten, finden Sie hier unsere Leistungen und Pläne. Unser Plan Run & monitor kostet CHF 750 pro Monat, unser Plan Guidance CHF 799 pro Monat.

Häufige Fragen

Was ist der Unterschied zwischen Throttling und Rate Limiting bei APIs?

Rate Limiting setzt eine harte Obergrenze für Anfragen in einem Zeitfenster und weist alles darüber zurück. Throttling ist breiter: Es formt den Verkehr, indem es Anfragen je nach Last verzögert, einreiht oder manchmal abweist. Wenn Sie steigende Latenz bei erfolgreichen Antworten sehen, werden Sie wahrscheinlich gedrosselt. Erhalten Sie sofort 429-Fehler, haben Sie eine harte Grenze erreicht.

Welchen Algorithmus für Rate Limiting soll ich verwenden?

Beginnen Sie mit einem Token Bucket, wenn Ihre Clients legitime Lastspitzen senden, oder mit einem Sliding-Window-Zähler, wenn Sie Spitzen an Fenstergrenzen ohne hohen Speicherbedarf vermeiden wollen. Für einfache Fälle mit geringem Risiko reichen feste Fenster. Einen Leaky Bucket wählen Sie, wenn ein empfindliches nachgelagertes System einen gleichmässigen Fluss braucht.

Soll ich nach IP-Adresse oder nach API-Schlüssel begrenzen?

Nutzen Sie bei authentifiziertem Verkehr den API-Schlüssel oder die Benutzer:in, denn das identifiziert den tatsächlichen Client. Die IP-Adresse eignet sich für anonyme Endpunkte wie Anmeldung und Registrierung, wobei viele Nutzer:innen dieselbe IP teilen können. In Multi-Tenant-Produkten ergänzen Sie ein Limit pro Mandant, damit eine Kundschaft die anderen nicht verdrängt.

Was soll meine API zurückgeben, wenn ein Limit überschritten wird?

Antworten Sie mit HTTP 429 Too Many Requests und einem Retry-After-Header, der dem Client die Wartezeit mitteilt. Ergänzen Sie normale Antworten um Header für Limit und Restmenge, damit Clients von sich aus langsamer werden. Dokumentieren Sie die Limits, damit Integrator:innen damit planen können.

Wie begrenze ich über mehrere Server hinweg?

Verwenden Sie einen gemeinsamen Speicher wie Redis mit atomaren Operationen, wenn Sie ein exaktes globales Limit brauchen, und nehmen Sie die zusätzliche Latenz sowie die neue Abhängigkeit in Kauf. Reicht ein Näherungswert, zählen Sie lokal pro Instanz oder pro Region und tolerieren Sie eine gewisse Überschreitung. Die richtige Wahl hängt davon ab, wie exakt das Limit sein muss.

Quellen

• Microsoft’s documentation
• preventing resource monopolization
• economics, performance, reliability, abuse severity and client awareness
• Gravitee’s explanation
• Zuplo
• throttling as delaying requests
• Requestly
• Vercel’s comparison
• Upstash’s documentation
• users or authorized applications
• per-tenant, per-endpoint limits
• Lua scripts to keep rate-limit operations atomic
• the effective global limit can multiply
• AWS SDKs
• Google Cloud recommends
• truncated exponential backoff with jitter
• shipping API integration pitfalls