Der Cache, der Latenz hinzufügte

Wir haben einen Redis-Cache eingebaut, um schneller zu werden. Er machte jeden Request langsamer.

Was wir gecacht haben:

• Nutzerprofile (bei jedem Request gelesen, aber so oft aktualisiert, dass die Einträge fast sofort veraltet waren)
• Warenkorb (nutzerspezifisch, volatil)
• Lagerbestände in Echtzeit

Das Problem:

• Cache Hit Rate: 3%
• 97% der Requests: Cache Miss + DB-Abfrage sowieso
• Jeder Request zahlte den Netzwerk-Roundtrip zu Redis: ~2ms
• Plus Serialisierung/Deserialisierung: ~5ms
• Netto: ~7ms reiner Overhead bei fast jedem Request — langsamer als ohne Cache

Was wir hätten cachen sollen:

• Produktkatalog (leseintensiv, ändert sich selten)
• Kategoriebaum (statisch)
• Feature Flags (global, ändern sich selten)
• Berechnete Aggregationen (teuer in der Berechnung)

Cache-Rechnung:

Benefit per request = (hit_rate × db_latency_saved) - cache_overhead

The overhead applies to every request.
The saving applies only to hits.
If benefit < 0, the cache is hurting you.

Korrigierte Version:

• Volatile Daten aus dem Cache entfernt
• Statische Inhalte mit langer TTL aufgenommen
• Hit Rate: 3% → 85%
• P50-Latenz: 150ms → 40ms

Lektion: Cachen Sie leseintensive Daten, die sich selten ändern. Nicht schreibintensive, volatile Daten. Den Request-Pfad zu profilen, bevor Infrastruktur dazukommt, ist das Erste, was wir in unseren DevOps-Engagements tun — der günstigste Cache ist der, den Sie nie gebraucht haben.

---

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