Unser Rate Limiter speicherte seinen Zustand in Redis. Redis fiel aus. Das Rate Limiting hörte auf. Der missbräuchliche Traffic, den es bis dahin still absorbiert hatte, nicht.

Der Zeitablauf:

  • 14:00 - Redis-Master für Wartung heruntergefahren; der Failover sprang nicht wie erwartet an
  • 14:01 - Der Rate Limiter konnte seinen Zustand nicht lesen/schreiben; Fail-open: alle Requests erlaubt
  • 14:02 - Der Scraper- und Bot-Traffic, den der Limiter bis dahin abgewehrt hatte — ein Mehrfaches unserer legitimen Last — traf ungedrosselt auf die API
  • 14:03 - API-Server gesättigt
  • 14:05 - Kompletter Ausfall

Der Designfehler:

Wir hatten es als binäre Wahl gerahmt: „Fail-open“ (alles erlauben) oder „Fail-closed“ (alles blockieren). Wir wählten Fail-open und haben die mittlere Option nie entworfen — weiter limitieren, nur mit gröberem lokalem Zustand.

Warum wir uns so entschieden haben:

„Wir wollen nicht, dass Redis-Probleme legitime Nutzer blockieren.“ Nachvollziehbar — ein volles Fail-closed hätte jeden Redis-Schluckauf in einen selbst verschuldeten Totalausfall verwandelt. Aber komplett offen war das andere Extrem.

Was wir hätten tun sollen:

  • In-Memory-Fallback-Rate-Limiter pro Instanz
  • Konservative Limits, wenn der gemeinsame Speicher nicht verfügbar ist — degradierte Durchsetzung, nicht keine
  • Redis-Replikation mit automatischem Failover, getestet, bevor er gebraucht wird
  • Rate Limiting auf mehreren Ebenen (CDN, API Gateway, App), damit kein einzelner Store tragend ist

Durchzuspielen, wie sich jede Kontrolle verhält, wenn ihre Abhängigkeiten sterben, ist ein Kernbestandteil unserer SecOps-Reviews — die meisten Teams haben die Frage nie gestellt, bis ein Incident sie beantwortet.

Lektion: Ein Rate Limiter, der komplett offen ausfällt, ist keine Kontrolle, und einer, der komplett geschlossen ausfällt, ist ein Ausfallgenerator. Entwerfen Sie den degradierten Modus: lokaler Zustand, konservative Limits, mehrere Ebenen.

← Zurück zu Lessons Learned

Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.

Tags: #Redis #RateLimiting #API #Sicherheit