Caching ist einer der wirksamsten Hebel für Geschwindigkeit — und eine der häufigsten Quellen für schwer auffindbare Fehler. Das berühmte Bonmot, die zwei schwersten Probleme der Informatik seien Cache-Invalidierung und das Benennen von Dingen, trifft einen wahren Kern. Ein gut eingesetzter Cache macht eine Anwendung dramatisch schneller und entlastet Datenbank und Backend; ein schlecht eingesetzter liefert veraltete oder, im Multi-Tenant-Kontext, fremde Daten aus. Dieser Beitrag ordnet die Caching-Ebenen und -Entscheidungen für SaaS.
Die Caching-Ebenen verstehen
Caching findet auf mehreren Ebenen statt, und jede hat ihren Zweck. Der Browser-Cache und das CDN speichern statische Inhalte nah beim Nutzer. Der Application-Cache — oft ein schneller In-Memory-Speicher wie Redis — hält häufig benötigte Daten zwischen, um wiederholte teure Berechnungen oder Datenbankabfragen zu vermeiden. Der Datenbank-Cache und das Query-Caching beschleunigen wiederkehrende Abfragen. Jede Ebene löst ein anderes Problem; eine durchdachte Strategie kombiniert sie bewusst, statt blind überall zu cachen.
Was sich zum Cachen eignet
Nicht alles gehört in den Cache. Gute Kandidaten sind Daten, die teuer zu beschaffen sind und sich selten ändern: aufwendige Aggregationen, selten geänderte Konfigurationen, Ergebnisse langsamer externer Aufrufe, aufbereitete Inhalte. Schlechte Kandidaten sind Daten, die sich häufig ändern und bei denen Aktualität kritisch ist — etwa Kontostände, Echtzeit-Verfügbarkeiten oder sicherheitsrelevante Berechtigungen. Die Faustregel: Je teurer die Beschaffung und je seltener die Änderung, desto besser eignet sich etwas zum Cachen. Cachen Sie das Teure und Stabile, nicht das Billige und Flüchtige.
Die Kunst der Invalidierung
Das eigentliche Problem ist nicht das Cachen, sondern das rechtzeitige Verwerfen veralteter Einträge. Mehrere Strategien stehen zur Wahl. Beim zeitbasierten Ansatz (TTL) verfällt ein Eintrag nach einer festen Zeit — einfach, aber er liefert bis zum Verfall potenziell veraltete Daten. Beim ereignisbasierten Ansatz wird ein Eintrag aktiv verworfen, sobald sich die zugrunde liegenden Daten ändern — präziser, aber aufwendiger, weil jede Änderung wissen muss, welche Cache-Einträge sie betrifft. In der Praxis kombiniert man beides: ereignisbasierte Invalidierung für kritische Daten, eine TTL als Sicherheitsnetz für den Fall, dass eine Invalidierung übersehen wird.
Mandantentrennung im Cache
Im Multi-Tenant-SaaS lauert im Cache eine besonders gefährliche Falle: Ein Cache-Schlüssel, der den Mandanten nicht berücksichtigt, kann dazu führen, dass ein Kunde die gecachten Daten eines anderen sieht — eines der schwerwiegendsten Datenlecks überhaupt. Jeder Cache-Schlüssel im Multi-Tenant-Kontext muss deshalb den Mandanten eindeutig enthalten. Prüfen Sie diese Regel besonders sorgfältig, denn der Fehler ist im Test schwer zu bemerken und zeigt sich erst, wenn zwei Mandanten zufällig denselben Schlüssel treffen. Eine konsequente Konvention für mandantenbezogene Cache-Schlüssel ist hier die wirksamste Prävention.
Die Gefahr des veralteten Caches
Der subtilste Schaden eines Caches ist die stille Auslieferung veralteter Daten. Ein Nutzer ändert eine Einstellung, aber die alte ist noch im Cache — und er sieht seine Änderung nicht, hält das Produkt für fehlerhaft. Solche Fehler sind schwer zu reproduzieren, weil sie vom Cache-Zustand abhängen. Die Gegenmittel: kritische, vom Nutzer unmittelbar erwartete Daten gar nicht oder nur sehr kurz cachen, ereignisbasierte Invalidierung für alles, was der Nutzer selbst ändert, und im Zweifel die konservativere Wahl treffen — lieber etwas langsamer und korrekt als schnell und falsch.
Beobachtbarkeit des Caches
Ein Cache, dessen Wirkung man nicht misst, ist eine Blackbox. Beobachten Sie die Trefferquote (Hit Rate) — wie oft eine Anfrage aus dem Cache statt aus der Quelle bedient wird. Eine niedrige Trefferquote bedeutet, dass der Cache wenig nützt, vielleicht weil die TTL zu kurz ist oder die falschen Daten gecacht werden. Beobachten Sie zudem, ob nach Datenänderungen veraltete Daten ausgeliefert werden. Diese Sichtbarkeit erlaubt es, die Caching-Strategie datengetrieben zu justieren, statt nach Gefühl zu cachen.
Fazit
Caching ist ein mächtiger Geschwindigkeitshebel, der mit Sorgfalt eingesetzt werden muss. Verstehen Sie die verschiedenen Ebenen und cachen Sie bewusst das Teure und Stabile, nicht das Billige und Flüchtige. Beherrschen Sie die Invalidierung durch eine Kombination aus ereignisbasiertem Verwerfen und einer TTL als Sicherheitsnetz, verankern Sie den Mandanten zwingend in jedem Cache-Schlüssel und treffen Sie bei kritischen, nutzererwarteten Daten die konservative Wahl. Machen Sie die Wirkung des Caches über Trefferquoten messbar. Wer Caching so diszipliniert einsetzt, gewinnt erhebliche Geschwindigkeit, ohne die schwer auffindbaren Fehler zu erzeugen, die unsauberes Caching berüchtigt machen.
Caching und Konsistenzanforderungen
Bevor Sie überhaupt cachen, lohnt eine bewusste Entscheidung über die Konsistenzanforderung pro Datenart. Manche Daten dürfen kurz veraltet sein, ohne dass es jemanden stört — eine Statistik, die ein paar Minuten alt ist, ist meist unproblematisch. Andere Daten müssen strikt aktuell sein, weil eine veraltete Anzeige zu falschen Entscheidungen oder zu Verwirrung führt. Diese Unterscheidung — eventual consistency versus strikte Aktualität — sollten Sie pro Datenart treffen, bevor Sie die Caching-Strategie festlegen. Sie bestimmt, was Sie überhaupt cachen dürfen und wie aggressiv.
Ein praktischer Rat aus dem Betrieb mehrerer Produkte: Beginnen Sie konservativ und cachen Sie zunächst nur das eindeutig Unkritische und Teure. Erweitern Sie das Caching dann gezielt dort, wo die Messung einen echten Performance-Engpass zeigt, der durch Cachen lösbar ist. Der umgekehrte Weg — überall aggressiv cachen und dann die Konsistenzfehler einsammeln — kostet weit mehr Zeit in der Fehlersuche, als das Caching an Performance bringt. Caching ist eine Optimierung, und Optimierungen verdienen Messung als Voraussetzung, nicht Annahme.