Caches sind keine Lösung

Caches lösen keine Probleme. Sie verstecken sie.

Der Neustart, der alles offenlegt

Services neu deployt, Pods hochgefahren, alles grün. Und dann: Timeouts. Die ersten Requests laufen ins Leere, weil irgendein „3rd Level Cache“ noch kalt ist. Das Team wartet. Die Nutzer warten. Irgendwann sind die Caches warm, alles läuft wieder. Bis zum nächsten Neustart.

Das ist kein Caching-Problem. Das ist ein Architektur-Problem, das sich als Caching-Lösung verkleidet hat.

Die Verwechslung

Caching ist eine Optimierung. Eine gute, oft sinnvolle Optimierung. Aber irgendwann hat sich in vielen Teams ein Denkfehler eingeschlichen: Die Query ist zu langsam? Cache drauf. Der Service antwortet nicht schnell genug? Cache davor. Das Datenmodell gibt die Antwortzeit nicht her? Cache drumherum.

Das funktioniert — solange der Cache da ist. Aber ein Cache, den du nicht ausschalten kannst, ohne dass die App zusammenbricht, ist keine Optimierung mehr. Er ist eine Krücke.

Der Unterschied ist fundamental:

• Optimierung: Die App funktioniert ohne Cache. Mit Cache ist sie schneller. Gut.
• Krücke: Die App funktioniert ohne Cache nicht. Der Cache kompensiert ein Problem, das niemand gelöst hat.

Der Lackmustest

Eine einfache Frage reicht: Funktioniert die App ohne Cache?

Nicht „ist sie schnell genug für Production“. Sondern: Funktioniert sie überhaupt? Antwortet sie, ohne in Timeouts zu laufen? Kann ein Nutzer seine Aufgabe erledigen — vielleicht langsamer, aber er kann?

Wenn nein, dann hast du kein Cache-Problem. Du hast ein Performance-Problem. Der Cache versteckt es nur.

Und versteckte Probleme sind die teuersten. Sie melden sich nicht im Monitoring. Im Sprint-Planning tauchen sie nie auf. Stattdessen wachsen sie still, bis sie bei einem Neustart, einem Failover oder einer Lastspitze plötzlich sichtbar werden — zum ungünstigsten Zeitpunkt.

Was stattdessen

Die Reihenfolge ist einfach:

1. Messen. Wo ist die App ohne Cache tatsächlich langsam? Nicht raten — messen.
2. Ursache beheben. Fehlende Indices. N+1-Queries. Ein Datenmodell, das für den Lesezugriff nicht gemacht ist. Overfetching. Synchrone Aufrufe, die asynchron sein könnten.
3. Dann — optional — cachen. Wenn die App ohne Cache funktioniert und der Cache sie noch schneller macht: perfekt. Das ist eine Optimierung. Das ist, wofür Caches da sind.

Der entscheidende Punkt: Schritt 3 ist optional. Wenn du nach Schritt 2 feststellst, dass die Performance reicht — brauchst du keinen Cache. Weniger bewegliche Teile, weniger Invalidierungs-Logik, weniger Fehlerquellen. Weniger ist oft besser.

Fazit

Caches sind großartig — als Optimierung. Als Sahnehäubchen auf einer App, die auch ohne sie funktioniert. Aber als Fundament? Als Voraussetzung dafür, dass der Service überhaupt antwortet?

Dann ist der Cache nicht die Lösung. Dann ist er der Grund, warum du die eigentliche Lösung nie gesucht hast.