API Rate Limiting: 5 Strategien für robuste Backends

October 17, 2026

Rate Limiting wird in vielen Architekturdiagrammen als simples Häkchen abgetan: Ein Reverse Proxy oder ein API Gateway davor, 100 Requests pro Minute konfigurieren, fertig. In der Praxis kollabieren genau diese leichtfertig aufgesetzten Schutzmechanismen unter realer Produktionslast. Entweder blockieren sie legitime Kunden bei unvorhergesehenen Lastspitzen, öffnen Angreifern für Credential Stuffing Tür und Tor oder reißen bei einem DDOS-Versuch das eigene Caching- und In-Memory-Backend in den Abgrund.

Wer APIs gegen Missbrauch, Noisy Neighbors und Lastspitzen absichern will, muss tief in Algorithmen, atomare Datenspeicher und Proxy-Architekturen eintauchen.

Die Wahl des Algorithmus entscheidet maßgeblich über Speichereffizienz und Glättungsverhalten deiner Infrastruktur.

Der einfachste Ansatz zählt Requests innerhalb fester Zeitfenster (z. B. 00:00 bis 00:01). Das spart Speicher, birgt jedoch das berüchtigte 2x-Burst-Problem: Erlaubt ein Service 100 Requests pro Minute und ein Client sendet 100 Anfragen um 00:00:59 sowie weitere 100 um 00:01:01, verarbeitet das System 200 Anfragen innerhalb von zwei Sekunden. Nachgelagerte Datenbanken brechen hier regelmäßig ein.

Das gleitende Zeitfenster auf Basis von Logs (Sliding-Window-Log) eliminiert Randeffekte vollständig, indem jeder Request als Timestamp in einer Datenstruktur hinterlegt wird. In Redis geschieht dies meist über Sorted Sets (ZSET).

Viele Teams laufen hier jedoch in die ZSET-Speicherfalle: Jeder API-Aufruf fügt ein Element mit ZADD hinzu. Wird ZREMRANGEBYSCORE nicht strikt vor der Abfrage (ZCARD) ausgeführt oder vergessen Entwickler, inaktiven Keys eine harte TTL zuzuweisen, wächst der RAM-Bedarf ins Unermessliche. Bei O(N)-Speicherkomplexität führt dies schnell zu massiver Redis-Fragmentierung und OOM-Kills.

Der Sliding-Window-Counter bietet einen exzellenten Kompromiss mit O(1)-Speicher. Er gewichtet den Zähler des vorherigen Fensters anteilig zur verstrichenen Zeit des aktuellen Fensters. Für APIs, die kurze, kontrollierte Bursts erlauben müssen (etwa Page Loads mit vielen Sub-Ressourcen), bleibt der Token-Bucket-Algorithmus die Referenz: Tokens laufen kontinuierlich nach; sind Tokens verfügbar, wird der Request sofort durchgelassen.

Verteiltes Rate Limiting erfordert zentrale State-Stores wie Redis. Wer hier naiv vorgeht, baut sich gefährliche Race Conditions ein:

1. GET key (Lese aktuellen Zähler)
2. IF counter < limit THEN counter++
3. SET key counter

Bei parallelen Requests schlägt dieses Check-then-Act-Muster fehl. Clients umgehen das Limit mühelos. Verteilte Locks via Redlock erzeugen immensen Latenz-Overhead. Die performante Lösung: Atomare Lua-Skripte, die direkt im Single-Threaded-Kontext von Redis laufen.

local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local refill_rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])

local data = redis.call('HMGET', key, 'tokens', 'last_updated')
local tokens = tonumber(data[1])
local last_updated = tonumber(data[2])

if tokens == nil then
    tokens = capacity
    last_updated = now
else
    local delta = math.max(0, now - last_updated)
    tokens = math.min(capacity, tokens + delta * refill_rate)
    last_updated = now
end

if tokens >= requested then
    tokens = tokens - requested
    redis.call('HMSET', key, 'tokens', tokens, 'last_updated', last_updated)
    redis.call('EXPIRE', key, math.ceil(capacity / refill_rate))
    return 1
else
    redis.call('HMSET', key, 'tokens', tokens, 'last_updated', last_updated)
    return 0
end

Wird die Anwendung in einem Redis-Cluster betrieben, verteilt Redis Keys anhand von CRC16-Hash-Slots. Befinden sich in einem Lua-Skript mehrere Keys auf unterschiedlichen Shards, wirft Redis sofort einen CROSSSLOT Keys in request don't hash to the same slot-Fehler.

Lösung: Erzwinge die Slot-Zuweisung über Hash-Tags im Key-Namen. Nutze Strukturen wie {tenant:123}:ratelimit:api statt unstrukturierter Strings. Alles innerhalb der geschweiften Klammern bestimmt den Ziel-Node.

Ein globales Rate Limit reicht in modernen B2B-SaaS-Plattformen nicht aus. Ein Noisy Neighbor kann mit legitimen Batch-Imports die gesamte Shared-Infrastructure lahmlegen.

Implementiere Limits als dreistufige Kaskade:

1. Globales System-Limit: Schützt den Node vor Überlastung.
2. Tenant-Tier-Limit: Deckelt das Gesamtvolumen eines Kunden basierend auf seinem gebuchten Paket (z. B. 5.000 Req/Min für Enterprise, 200 Req/Min für Free).
3. User- & API-Key-Limit: Verhindert, dass ein einzelner fehlerhafter Skriptlauf eines Anwenders das gebuchte Kontingent des gesamten Mandanten aufbraucht.

Angreifer nutzen Distributed Botnets mit Tausenden rotierenden IP-Adressen. Ein reines IP-basiertes Rate-Limiting greift bei /auth/login ins Leere.

Wirksamer Schutz erfordert ein Dual-Key-Verfahren:

• Key 1: IP-Adresse kombiniert mit dem Hash des User-Agents.
• Key 2: Ein striktes Zählerlimit auf den anvisierten Ziel-Accountnamen (z. B. auth:target:{username_hash}).

Ergänze dies um Tarpitting: Statt Angreifern sofort mit 429 Too Many Requests zu signalisieren, dass sie weiterziehen müssen, verzögert der Server die Antwort künstlich um 1 bis 3 Sekunden. Das blockiert die Worker des Angreifers, frisst dessen Ressourcen und senkt die Angriffsfrequenz drastisch.

http {
    limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;
    limit_req_zone $binary_remote_addr$request_uri zone=login_abuse:10m rate=5r/m;

    server {
        location /api/v1/auth/login {
            limit_req zone=ip_limit burst=20 nodelay;
            limit_req zone=login_abuse burst=2 nodelay;
            limit_req_status 429;
            proxy_pass http://backend;
        }
    }
}

Ein oft übersehenes Ausfallszenario ist der sogenannte 429-Doomsday: Tausende API-Clients erhalten synchron ein 429 Too Many Requests. Wenn Clients anschließend im Sekundentakt anfragen, ob das Kontingent wieder frei ist, bricht nicht die Applikationslogik zusammen, sondern die Rate-Limiting-Schicht (Redis) selbst unter der schieren Last der Statusprüfungen.

1. Edge Caching für 429: Blockierte Anfragen sollten nach der ersten Bewertung direkt am Edge-Proxy (z. B. Nginx, Cloudflare) terminiert werden, ohne Redis erneut abzufragen.
2. Clients Disziplinieren: Sende immer standardisierte Header wie Retry-After: <seconds> mit. Clients müssen zwingend Exponential Backoff mit Full Jitter implementieren, um synchrone Lastspitzen (Thundering Herd) nach dem Intervall-Reset zu zerstreuen.

Aktiviere neue Limits niemals direkt im blockierenden Modus in Produktion. Setze ein Shadow-Deployment auf:

• Überschreitet ein Request das Limit, wird er nicht mit 429 abgewiesen.
• Setze stattdessen einen internen Header (z. B. X-RateLimit-Shadow-Exceeded: true) und logge das Event strukturiert in OpenTelemetry oder Elasticsearch.

Auf diese Weise erkennst du verdeckte Batch-Jobs, interne Cronjobs oder fehlkonfigurierte Webhooks deiner Schlüsselkunden, bevor es zu kritischen Betriebsausfällen kommt.

Wo gehört das Rate Limiting hin? Auf Applikationsebene oder in den Proxy?

• Nginx: Nutzt den Leaky-Bucket-Algorithmus (ngx_http_limit_req_module). Die Ratenbegrenzung erfolgt lokal pro Worker über Shared-Memory-Zonen. Das ist extrem schnell und ressourcenschonend, funktioniert aber primär isoliert auf einzelnen Maschinen.
• Envoy: Bietet eine mächtige Trennung zwischen Local Rate Limiting (Token-Bucket pro Envoy-Instanz) und Global Rate Limiting über einen externen gRPC-Service (RLS). Dies erlaubt systemweite Koordination über hunderte Microservice-Instanzen hinweg.

http_filters:
  - name: envoy.filters.http.ratelimit
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.ratelimit.v3.RateLimit
      domain: api_services
      failure_mode_deny: false
      rate_limit_service:
        grpc_service:
          envoy_grpc:
            cluster_name: rate_limit_service_cluster
      descriptors:
        - actions:
            - request_headers:
                header_name: X-Tenant-ID
                descriptor_key: tenant_id
            - remote_address: {}
              descriptor_key: client_ip

Setze Failure-Mode auf failure_mode_deny: false, damit ein temporärer Ausfall des Rate-Limiting-Dienstes nicht deine gesamte API lahmlegt (Fail-Open).

Robuste API-Sicherheit erfordert eine saubere Balance aus durchdachter Algorithmenwahl, performantem State-Management und intelligenter Lastverteilung an der Systemgrenze. Wenn du deine Backend-Architektur gegen Überlastung und Angriffe absichern willst, unterstütze ich dich gerne bei Konzeption und Umsetzung: Büngener Software.