L1-, L2- und L3-Cache hinzugefügt, für „bessere Performance“. Jetzt haben wir 3 Stellen, an denen Daten falsch sein können, statt 1.

Unsere brillante Architektur:

  • L1: In-Process-Cache (Guava)
  • L2: Lokales Redis
  • L3: Verteilter Redis-Cluster
  • Source of Truth: PostgreSQL

Was schiefging:

  • L3-Cache korrekt invalidiert
  • L2-Cache hatte noch alte Daten (andere TTL)
  • L1-Cache auf Server A hatte alte Daten
  • L1-Cache auf Server B hatte neue Daten
  • Nutzer sahen bei jedem Refresh andere Daten

Debugging-Hölle:

„Welche Cache-Schicht hat die falschen Daten?“ wurde jedes Mal zu einer 2-stündigen Untersuchung.

Was wir gelernt haben:

  • Jede Cache-Schicht multipliziert die Invalidierungskomplexität
  • TTLs müssen koordiniert werden (innerer Cache < äußerer Cache)
  • Observability in jede Schicht ist nötig
  • Manchmal reicht ein Cache

Lektion: Mehr Cache-Schichten ≠ bessere Performance. Es bedeutet mehr Stellen zum Debuggen, wenn etwas schiefgeht. Bevor Sie eine weitere Schicht hinzufügen, stellen Sie sicher, dass Ihr Monitoring- und Observability-Stack durch die vorhandenen hindurchsehen kann.

← 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 #Architektur #Performance #Debugging