Rate limiting und Schutz vor API-Missbrauch: Token Bucket, Leaky Bucket, Quoten, Backoff

Rate limiting ist eine Massnahme, die auf einem Diagramm simpel wirkt und in der Praxis sofort komplex wird: Mobile Apps wiederholen Anfragen bei instabilen Netzen, Partner-Integrationen schicken Batches, Bots rotieren IPs, und Hintergrundjobs erzeugen unbeabsichtigte Lastspitzen. Im Jahr 2026 kombinieren die meisten produktiven APIs mehrere Bausteine: Token Bucket für Burst-Toleranz, Leaky Bucket für Glättung, Quoten für faire Nutzung über längere Zeiträume und Backoff-Regeln, damit Retries eine Teilstörung nicht zu einem kompletten Ausfall eskalieren. Dieser Beitrag erklärt, wie diese Mechanismen zusammenwirken, wovor sie konkret schützen und welche Design-Entscheidungen in realen Systemen meist wichtiger sind als der Name des Algorithmus.

Was Rate limiting wirklich schützt: Verfügbarkeit, Kosten und Fairness

Im Kern verhindert Rate limiting, dass ein einzelner Client – absichtlich oder durch einen Fehler – überproportional viel Rechenzeit, Datenbank-Verbindungen oder Downstream-Kapazität verbraucht. Es geht nicht nur um “zu viele Requests”, sondern um den Schutz gemeinsam genutzter Ressourcen und um planbare Latenz für alle. Besonders kritisch sind Endpunkte mit teurem Fan-out, etwa Suche, Empfehlungen oder Aufrufe externer Dienste – dort kann eine Lastspitze schnell eine Warteschlangen-Spirale auslösen.

Ebenso wichtig ist die Kosten- und Vertragsseite. Öffentliche APIs hängen oft an einem Preismodell: Bandbreite, Compute-Zeit, bezahlte Stufen oder Partnervereinbarungen. Aber auch interne APIs sitzen häufig vor gemessenen Diensten oder knappen Budgets. Rate limiting macht solche Grenzen durchsetzbar, und Quoten schaffen Klarheit: Statt “Best effort” gibt es nachvollziehbare Erwartungen, die sich dokumentieren und bei Bedarf anpassen lassen.

Schliesslich ist Rate limiting ein Fairness-Werkzeug. Zwei Clients können legitim sein und sich trotzdem gegenseitig schaden: Der eine sendet gleichmässig, der andere schiesst jeweils am Minutenanfang Bursts. Ohne Mechanismen, die Bursts zulassen und gleichzeitig glätten, kann der spiky Client Concurrency dominieren und den stabilen Client in Timeouts drücken. Ein gutes Limit-Design sorgt für Vorhersagbarkeit und reduziert den Druck, Probleme nur über aggressives Autoscaling zu kaschieren.

Limits so wählen, dass sie echte Engpässe abbilden

Die erste Frage lautet: Was genau wird begrenzt? “Requests pro Sekunde” ist leicht zu messen, aber oft nicht kostengerecht. In der Praxis setzen viele Teams gewichtete Limits ein: Ein einfacher Read zählt 1 Einheit, eine komplexe Suche 5, ein Export 20. So orientiert sich die Begrenzung am realen Engpass – CPU, Datenbank-IO oder ein externer Anbieter mit harten Quoten – statt an einer reinen Request-Zählung.

Danach folgt der Scope: pro IP, pro API-Key, pro Nutzerkonto, pro Organisation oder pro Credential plus Route. Reine IP-Limits lassen sich durch Rotationen umgehen und bestrafen NAT-Netze (Unternehmen, Mobilfunk) ungerecht. Reine Key-Limits werden gefährlich, wenn ein Schlüssel kompromittiert wird. In vielen öffentlichen APIs ist daher ein mehrstufiges Modell sinnvoll: moderate IP-Schutzgeländer gegen triviales Scanning, stärkere Limits pro Key oder Konto für Fairness, plus route-spezifische Limits für besonders teure Endpunkte.

Auch das Zeitfenster ist eine Stabilitätsentscheidung. Sehr kurze Fenster (Sekunden) schützen die Moment-Kapazität, längere Fenster (Minute/Stunde/Tag) steuern dauerhafte Nutzung. Häufig bewährt sich ein bewusstes Zusammenspiel: ein kurzfristiges Burst-Limit, das Spitzen abfängt, und eine längerfristige Quote, die die Nutzung als vertragliche Regel über Zeiträume abbildet.

Token Bucket vs. Leaky Bucket: Bursts zulassen, Last glätten

Token Bucket und Leaky Bucket werden gern als Alternativen dargestellt, lösen in realen Systemen aber unterschiedliche Aufgaben. Token Bucket erlaubt Bursts: Tokens sammeln sich bis zu einer Kapazität an, und jede Anfrage “verbraucht” Tokens. War ein Client eine Weile ruhig, kann er kurzfristig mehr senden, ohne sofort geblockt zu werden. Das passt zu typischen Mustern – Apps wachen auf, Warteschlangen leeren sich, Partner senden Batches – und vermeidet, dass natürliche Nutzungsschwankungen unnötig bestraft werden.

Leaky Bucket zielt dagegen auf Glättung. Man kann es als Warteschlange verstehen, die mit konstanter Rate abfliesst. Treffen Requests schneller ein als der Abfluss, füllt sich die Queue; Überschuss wird verzögert oder abgewiesen. Das ist besonders nützlich, wenn der geschützte Teil des Systems Burst-Last schlecht verträgt: Datenbanken, die bei Connection-Spikes “kippen”, oder Downstream-Dienste mit strikten per-Sekunde-Grenzen.

In vielen Architekturen wird Token Bucket am Rand eingesetzt (Gateway, Reverse Proxy, Ingress), während leaky-bucket-artige Glättung näher am Engpass passiert (Worker-Queues, per-Tenant-Runner, Connection-Pools). Der Edge-Limiter schützt vor plötzlichen Fluten, und die interne Glättung schützt die fragilen Komponenten vor Jitter-Traffic, der ansonsten trotzdem durchschlägt.

Typische Fallstricke: verteilte Limits, Zeitfenster und Fehlalarme

Ein Klassiker ist der Versuch, ein einziges globales Limit über viele Nodes “perfekt” durchzusetzen, ohne die Konsequenzen zu bedenken. Wenn jeder Node separat “100 Requests/Sekunde” erlaubt, wird daraus effektiv “100 pro Node”. Um das zu vermeiden, braucht es gemeinsamen Zustand (z. B. ein zentrales Store) oder ein bewusstes Design aus lokalen Limits plus globalen Quoten, die weniger häufig geprüft werden. Auch 2026 akzeptieren viele Teams am Edge bewusst eine gewisse Ungenauigkeit, weil perfekte Konsistenz oft zu viel Latenz und Komplexität kostet.

Zeitfenster-Details sind ebenfalls tückisch. Fixed Windows (Reset jede Minute) erzeugen Grenz-Effekte, bei denen Clients um 12:00:00 spiken. Sliding Windows reduzieren das, sind aber rechenintensiver. Token Bucket vermeidet einige Boundary-Artefakte, trotzdem muss man Refill-Granularität wählen und entscheiden, ob Tokens kontinuierlich oder in Ticks nachgefüllt werden.

Viele Fehlalarme entstehen weniger durch den Algorithmus als durch Identität und Netz-Topologie. NAT, Carrier-Gateways und Unternehmens-Proxies lassen viele Nutzer wie eine IP wirken; Bot-Netze lassen einen Akteur wie viele IPs erscheinen. Wer nur auf IP-Limits setzt, blockiert echte Nutzer und bremst Angreifer kaum. Wer nur auf Keys setzt, riskiert bei Key-Leak Schaden über längere Zeit. Mehrschichtige Limits plus Anomalie-Signale (neue Regionen, ungewöhnliche Routen, extreme Error-Raten) senken beide Risiken.

Quoten und Backoff: Throttling als stabiler Vertrag

Rate limiting ohne klares Feedback führt zu schlechtem Client-Verhalten: enge Retry-Loops, zufällige Delays oder “einfach nochmal probieren” quer durch Codebasen. Quoten definieren dagegen, was faire Nutzung über längere Zeiträume bedeutet – pro Minute, Stunde oder Tag – und ermöglichen saubere Stufenmodelle oder Partner-Allokationen. Quoten helfen auch im Incident-Management: Bei Teilstörungen lassen sich Budgets temporär reduzieren, kritische Clients priorisieren und das System stabilisieren, statt in dauerndes Thrashing zu geraten.

Backoff verhindert, dass Retries zum Verstärker werden. Wenn ein Dienst degradiert, steigt die Latenz und die Fehlerrate. Clients, die sofort erneut senden, erhöhen die Last und verschlimmern die Lage. Exponentielles Backoff mit Jitter ist 2026 der Standard, weil es Retries über Zeit verteilt und synchronisierte Retry-Stürme verhindert. Der Jitter-Anteil ist entscheidend: Verdoppeln alle Clients in perfektem Gleichschritt, kollidieren sie weiterhin.

Damit Quoten und Backoff zusammen funktionieren, braucht es konsistente Signale. Wenn gedrosselt wird, sollte ein passender Status zurückkommen (häufig HTTP 429) und – wenn möglich – eine konkrete Warteempfehlung. Je klarer und vorhersehbarer diese Hinweise sind, desto eher lassen sich sichere Retry-Regeln in SDKs zentral implementieren, statt dass jede Integration improvisieren muss.

Antworten in der Praxis: 429, Header und robustes Client-Verhalten

Eine gute Throttling-Antwort ist explizit und maschinenlesbar. Für HTTP-APIs wird 429 häufig genutzt, um ein überschrittenes Limit zu signalisieren, und viele Clients kennen dieses Muster bereits. Ein Retry-After-Header ist hilfreich, wenn sich ein sinnvoller Delay berechnen lässt. Selbst wenn er nicht millisekundengenau ist, verhindert ein konservativer Wert unmittelbares “Hämmern” und reduziert verschwendeten Traffic.

Zusätzlich lohnt es sich, Limits als Teil des Vertrags sichtbar zu machen, damit Clients sich selbst regulieren können. Viele APIs liefern Limit- und Remaining-Werte über Response-Header oder in der Dokumentation. Wichtig ist dabei eindeutige Semantik: “Remaining” kann pro Minute, pro Stunde oder als Rolling Window gelten – wenn Clients raten müssen, verhalten sie sich oft falsch. Bei mehreren Limitern (Burst pro Sekunde plus Quote pro Tag) sollte klar sein, welches Signal zu welcher Grenze gehört.

Auf Client-Seite gehören zu sicherem Verhalten meist: exponentielles Backoff mit Jitter, ein Max-Backoff-Cap, eine maximale Retry-Anzahl und Idempotenz für Aktionen, die wiederholt werden könnten. Gerade bei Writes entscheidet ein Idempotency-Key darüber, ob ein Retry harmlos ist oder etwa eine Zahlung doppelt auslöst. Backoff ist damit nicht nur Performance-Tuning, sondern Teil der Korrektheit: Es schützt den Dienst und gleichzeitig Nutzer vor Duplikaten und verwirrenden Teilfehlern.