Eine Aktion endete. Der Cache hat die Nachricht nicht bekommen. Vier weitere Stunden lang kauften Kunden $500-Artikel zum Aktionspreis von $350.

Was passiert ist:

  • Der Admin beendete die Aktion und stellte den regulären Preis in der Datenbank wieder her
  • Die Cache-TTL betrug 6 Stunden
  • Keine Cache-Invalidierung beim Update
  • Die API lieferte den gecachten (Aktions-)Preis aus
  • 327 Bestellungen zum abgelaufenen Preis
  • Rund $49.000 an ungewollten Rabatten, bevor es jemandem auffiel

Ursache:

Das Admin-Panel aktualisierte die Datenbank direkt. Die Cache-Schicht hatte keine Ahnung, dass sich etwas geändert hatte.

Die Lösung:

  • Write-through-Cache: Updates laufen durch die Cache-Schicht
  • Event-getriebene Invalidierung: Datenbankänderungen lösen das Leeren des Caches aus
  • Kürzere TTL für preissensible Daten (5 Minuten)
  • Manueller Cache-Flush-Button für Admins

Lektion: Cache-Invalidierung ist schwer, weil Sie jede Stelle kennen müssen, an der sich Daten ändern können. Ein übersehener Pfad = Desaster durch veraltete Daten. Die längere Version davon, wie das selbst mit vorhandener Invalidierung schiefgeht, lesen Sie in unserem Cache-Invalidierungs-Albtraum.

← 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: #Caching #Datenkonsistenz #Debugging #Redis