Session Storage für horizontale Skalierung nach Redis migriert. Vergessen, dass ein Redis-Neustart jeden Nutzer ausloggt.

Vorher:

  • Sessions In-Memory auf jedem Server gespeichert
  • Sticky Sessions über den Load Balancer
  • Funktioniert bei kleiner Skalierung problemlos

Die Migration:

  • Sessions zentral in Redis
  • Keine Sticky Sessions mehr nötig
  • Horizontale Skalierung möglich

Was wir vergessen haben:

  • Redis ist standardmäßig In-Memory
  • Neustart = alle Sessions weg
  • 50.000 Nutzer gleichzeitig ausgeloggt
  • Support-Tickets: „Warum wurde ich ausgeloggt?“

Der Fix:

  • Redis-Persistenz (RDB-Snapshots + AOF mit appendfsync everysec) — das verkleinert das Verlustfenster auf etwa eine Sekunde an Schreibvorgängen; es mildert das Logout-Ereignis, beseitigt es aber nicht
  • Replikation mit automatischem Failover (Redis Sentinel), damit der Neustart eines einzelnen Knotens nicht mehr bedeutet, dass der Session Store weg ist
  • Beim Login zusätzlich zur Redis-Session ein signiertes JWT ausstellen — nur weil beide Credentials von Anfang an existieren, kann die App auf zustandslose Auth zurückfallen, wenn Redis nicht erreichbar ist
  • Rolling Restarts gegen Replicas in Wartungsfenstern, nie ein Cold Restart des einzigen Knotens

Zu entscheiden, wo Session-State lebt — und was passiert, wenn dieser Store neu startet — ist eine der ersten Fragen, die wir in Cloud-Migrationsprojekten durcharbeiten.

Lektion: In-Memory-Speicher ist flüchtig. Wenn der Verlust der Daten Nutzer trifft, brauchen Sie Persistenz und Redundanz.

← 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 #Sessions #Migration #Architektur