Zum Hauptinhalt springen

Rate Limiting

Einleitung​

Rate Limiting begrenzt die Anzahl von Anfragen innerhalb eines definierten Zeitraums, um:

  • Überlastung zu verhindern
  • faire Ressourcennutzung sicherzustellen
  • Missbrauch zu begrenzen

Es ist ein Schutzmechanismus gegen Überlast und unkontrolliertes Wachstum.

Grundsatz:

Nicht jeder Traffic ist gleich wertvoll.

Einordnung

Rate Limiting ist ein Resilience- und Traffic-Control-Pattern.

Typische Einsatzorte:

  • API Gateway
  • Edge Layer
  • Service Mesh
  • service-nahe Middleware

Es wirkt vor allem auf der Ingress-Seite eines Systems.

Ziele

  • Systemstabilität unter Last
  • Fairness zwischen Konsumenten
  • Schutz vor Missbrauch (Scraping, DDoS light)
  • Kostenkontrolle bei teuren Ressourcen

Grundprinzip

Algorithmen

1️⃣ Fixed Window​

  • X Requests pro Zeitfenster
  • Einfach
  • Burst am Fensterende möglich

2️⃣ Sliding Window​

  • Gleitendes Zeitfenster
  • Gleichmäßigere Begrenzung
  • Höherer Rechenaufwand

3️⃣ Token Bucket​

  • Tokens werden pro Zeit regeneriert
  • Burst bis zur Bucket-Größe erlaubt
  • Sehr verbreitet im API-Umfeld

4️⃣ Leaky Bucket​

  • Gleichmäßiger Abfluss
  • Stärker regulierend
  • Gut für Traffic Shaping

Harte vs. weiche Limits

Hard Limit​

  • Überschreitung → 429
  • Sofortige Ablehnung

Soft Limit​

  • Priorisierung
  • Verzögerung
  • abgestufte Antwortzeiten

Verteilte Systeme: besondere Herausforderungen

1️⃣ Mehrere Instanzen​

Lokale Zähler führen zu:

  • inkonsistenten Limits

Lösungen:

  • zentraler Redis
  • verteiltes Rate-Limit-System
  • API-Gateway-Durchsetzung

2️⃣ Multi-Tenant-Systeme​

Limits können gelten für:

  • IP
  • API-Key
  • Tenant
  • User
  • Endpunkt

Granularität ist Designentscheidung.

3️⃣ Retry + Rate Limiting​

Unkontrollierte Retries können:

  • Limits verstärken
  • Systeme weiter destabilisieren

Retry muss mit Backoff kombiniert werden.

Vorteile

  • Schutz vor Überlast
  • Fairness zwischen Konsumenten
  • Kapazitätskontrolle
  • Schutz kostenintensiver Ressourcen

Risiken / typische Fallstricke

1️⃣ Falsche Schwellenwerte​

Zu niedrig:

  • legitime Nutzer blockiert

Zu hoch:

  • Schutz wirkungslos

2️⃣ Fehlende Transparenz​

Ohne:

  • Dokumentation
  • Rate-Limit-Headers
  • Retry-After-Angaben

verschlechtert sich Developer Experience erheblich.

3️⃣ Kein Ersatz für Skalierung​

Rate Limiting:

  • schützt Systeme
  • ersetzt keine Kapazitätsplanung

4️⃣ Verwechslung mit Backpressure​

Rate Limiting:

  • reguliert Eingang

Backpressure:

  • reguliert interne Verarbeitungskapazität

Beides ergänzt sich.

Wann sinnvoll?

  • öffentliche APIs
  • Multi-Tenant-Plattformen
  • kostenintensive Services
  • stark schwankende Last

Wann weniger relevant?

  • interne Low-Traffic-Systeme
  • isolierte Batch-Jobs
  • Single-Tenant-Umgebungen mit klarer Lastkontrolle

Strategische Perspektive

Rate Limiting ist:

  • kein Business-Feature
  • kein Performance-Feature

Es ist ein Stabilitäts- und Governance-Mechanismus.

Es verschiebt die Diskussion von:

„Wir skalieren immer weiter“

zu:

„Welche Last ist akzeptabel?“

Fazit

Rate Limiting:

  • schützt Systeme vor Überlast
  • erzwingt Fairness
  • stabilisiert APIs

Es muss:

  • bewusst getunt
  • sauber kommuniziert
  • zentral durchgesetzt

werden.

Ohne Monitoring ist es blind.