API Rate Limiting erklärt: Wie Services den Request-Verkehr kontrollieren

API-Rate-Limiting ist eine Technik, die steuert, wie viele Anfragen ein Client innerhalb eines bestimmten Zeitfensters an eine API senden darf. Wenn ein Client dieses Limit überschreitet, lehnt der Server weitere Anfragen ab, bis das Zeitfenster zurückgesetzt wird. Es ist der Hauptmechanismus, den Dienste zur Drosselung von Anfragen, zur Verwaltung von Kontingenten und zum Schutz vor Missbrauch oder versehentlicher Überlastung einsetzen.

Warum Rate-Limiting notwendig ist

Eine API ohne Rate-Limiting ist eine offene Einladung zum Chaos. Ein einzelner fehlerhafter Client, eine fehlerhafte Retry-Schleife oder ein bewusster Denial-of-Service-Angriff können alle verfügbaren Serverressourcen aufbrauchen und den Dienst für alle lahmlegen. Rate-Limiting löst mehrere unterschiedliche Probleme gleichzeitig:

• DoS- und DDoS-Prävention: Begrenzt den Schaden, den eine einzelne Quelle durch Überflutung des Servers mit Traffic verursachen kann.
• Faire Nutzung: Verhindert, dass ein einzelner intensiver Nutzer andere Clients auf gemeinsam genutzter Infrastruktur aushungert.
• Kostenkontrolle: Cloud-Computing, Datenbankabfragen und Aufrufe von Drittanbieter-APIs kosten Geld. Limits halten die Rechnungen vorhersehbar.
• API-Schutz: Verlangsamt Credential-Stuffing-Angriffe und automatisiertes Scraping, die auf hohe Anfragevolumen angewiesen sind.
• SLA-Durchsetzung: Bezahlte Tarife können technisch durchgesetzt werden, nicht nur vertraglich.

So funktioniert es: Die Grundmechaniken

Im einfachsten Fall sitzt ein Rate-Limiter vor deiner API und verfolgt einen Zähler für jede Client-Identität. Diese Identität ist normalerweise eine der folgenden:

• IP-Adresse (grob, leicht zu spoofing)
• API-Schlüssel oder OAuth-Token (genau, an ein Konto gebunden)
• Benutzer-ID (für authentifizierte Endpoints)
• Eine Kombination, etwa IP plus Endpoint-Pfad

Jede eingehende Anfrage erhöht den Zähler. Wenn der Zähler das konfigurierte Limit überschreitet, bevor das Zeitfenster abläuft, gibt der Server HTTP 429 Too Many Requests zurück und die Anfrage wird verworfen oder in eine Warteschlange eingereiht. Wenn das Fenster zurückgesetzt wird, wird der Zähler gelöscht und der Client kann erneut senden.

Der Ort, an dem dieser Zähler gespeichert wird, ist entscheidend. In-Memory-Zähler auf einem einzelnen Server sind schnell, funktionieren aber nicht, sobald du horizontal skalierst. Produktionssysteme speichern den Rate-Limit-Status fast immer in einem gemeinsamen Cache, meist Redis, damit jeder Knoten im Cluster den gleichen Zählerstand sieht.

Gängige Rate-Limiting-Algorithmen

Der Algorithmus, den du wählst, bestimmt, wie "bursty" (stoßweise) Traffic gehandhabt wird. Jeder hat echte Kompromisse.

Der Token Bucket ist der am weitesten verbreitete Algorithmus in echten APIs. GitHub, Stripe und AWS verwenden alle Varianten davon, weil er kurze Bursts (ein Benutzer klickt schnell mehrere Dinge) natürlicherweise berücksichtigt, ohne anhaltende Fluten zuzulassen.

Rate-Limit-HTTP-Header in der Praxis

Wenn eine API Rate-Limiting durchsetzt, teilt sie den aktuellen Status über Response-Header mit. Es gibt keinen einzigen universellen Standard, aber zwei Konventionen dominieren:

Ältere Konvention (verwendet von Twitter/X, GitHub v3 und vielen anderen):

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 43
X-RateLimit-Reset: 1719878400

IETF-Entwurfsstandard (RateLimit-Header-Felder, draft-ietf-httpapi-ratelimit-headers):

RateLimit-Limit: 60
RateLimit-Remaining: 43
RateLimit-Reset: 17

Der Hauptunterschied: Das ältere X-RateLimit-Reset ist ein Unix-Zeitstempel, während die IETF-Version Sekunden bis zum Reset ist. Überprüfe immer die Dokumentation der jeweiligen API, die du integrierst.

Wenn das Limit erreicht wird, sollte der Server auch einen Retry-After Header zurückgeben, der dem Client genau mitteilt, wie viele Sekunden er warten soll, bevor er es erneut versucht. Nicht jede API sendet ihn, aber gut gepflegte tun es.

Kontingentmanagement vs. Rate-Limiting

Diese beiden Begriffe sind verwandt, aber nicht identisch, und ihre Verwechslung verursacht echte Integrationsfehler.

• Rate-Limiting steuert die Geschwindigkeit von Anfragen: 100 Anfragen pro Minute, 10 Anfragen pro Sekunde.
• Kontingentmanagement steuert das Volumen über einen längeren Zeitraum: 10.000 Anfragen pro Tag, 1 Million API-Aufrufe pro Monat.

Eine einzelne API kann beide gleichzeitig durchsetzen. Google Maps Platform wendet beispielsweise Pro-Sekunden-Rate-Limits UND monatliche Kontingentgrenzen an. Du kannst gut innerhalb deines monatlichen Kontingents liegen, aber dennoch gedrosselt werden, wenn du 50 Anfragen in einer Sekunde sendest. Das Erreichen des monatlichen Kontingents gibt einen anderen Fehlercode zurück (oft 403 mit einer Kontingent-überschritten-Meldung) als das Erreichen des Pro-Sekunden-Rate-Limits (429).

Umgang mit 429 zu viele Anfragen in deinem Code

Eine429 zu erhalten ist kein fataler Fehler. Die API sagt dir, dass du langsamer werden sollst. Die richtige Reaktion ist ein exponentieller Backoff mit Jitter.

Hier ist ein minimales Python-Beispiel:

import time
import random
import requests

def call_with_backoff(url, headers, max_retries=5):
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers)
        if response.status_code == 429:
            retry_after = int(response.headers.get("Retry-After", 2 ** attempt))
            jitter = random.uniform(0, 1)
            time.sleep(retry_after + jitter)
            continue
        response.raise_for_status()
        return response
    raise Exception("Max retries exceeded")

Wichtige Punkte in diesem Muster:

• Lese Retry-After zuerst. Wenn die API sie bereitstellt, verwende sie statt zu raten.
• Füge zufällige Jitter hinzu, damit mehrere Clients nicht alle im gleichen Moment erneut versuchen (das "Thundering Herd"-Problem).
• Begrenzen die Anzahl der Wiederholungen. Eine unendliche Retry-Schleife ist selbst eine Form von Missbrauch.
• Protokolliere die 429-Responses. Häufiges Rate-Limiting ist ein Signal, dass du Ergebnisse zwischenspeichern, Anfragen zusammenfassen oder deinen Plan upgraden musst.

Der MDN Web Docs Eintrag für HTTP 429 hat eine prägnante Referenz für die Statuscode-Semantik, wenn du die Spezifikationsebene-Details möchtest.

Praktische Rate-Limit-Beispiele

Wenn du dir ansiehst, wie große APIs dies implementieren, werden die Konzepte konkret:

Best Practices für API-Nutzer und Anbieter

Ob du eine API baust oder eine nutzt, die gleichen Prinzipien gelten auf beiden Seiten.

Wenn du eine API nutzt:

• Speichere Responses aggressiv zwischen. Die billigste Anfrage ist eine, die du nie sendest.
• Batch-Anfragen, wo die API es unterstützt (z.B. 100 Datensätze in einem Aufruf abrufen statt 100 einzelne Aufrufe).
• Verwende Webhooks oder Server-Sent Events statt Polling, wenn die API sie anbietet.
• Überwache deinen X-RateLimit-Remaining Header proaktiv, nicht nur wenn du 429 erreichst.
• Implementiere Circuit Breaker in langfristigen Diensten, damit eine gedrosselte API nicht zu einem vollständigen Anwendungsausfall führt.

Wenn du eine API baust:

• Wende Limits auf der API-Gateway-Ebene an (Kong, AWS API Gateway, Nginx), nicht innerhalb jedes Microservices.
• Differenziere Limits nach Tier: kostenlose Nutzer erhalten 100 RPM, bezahlte Nutzer 1.000 RPM.
• Gib immer Retry-After in 429-Responses zurück. Clients, die es respektieren, fahren sauber herunter.
• Protokolliere Rate-Limit-Ereignisse. Ein Client, der ständig Limits erreicht, hat entweder einen Bug oder ist ein böser Akteur.
• Dokumentiere deine Limits klar. Undokumentierte Limits sind ein Support-Albtraum.

Konfiguriere die Traffic-Kontrolle deines Servers ohne Code zu schreiben

Die Verwaltung von API-Rate-Limiting und Traffic-Kontrolle beginnt oft auf der Server-Konfigurationsebene. DevToolBox bietet Entwicklern kostenlose browsergestützte Tools zum Generieren, Testen und sofortigen Kopieren von Serverkonfigurationen, damit du weniger Zeit mit Boilerplate und mehr Zeit mit deiner eigentlichen API-Logik verbringst.

Probiere unsere kostenlosen Tools aus →