Entscheidung: welche Caching-Strategie?

Ein Cache hält häufig gelesene Daten in einer schnellen Schicht vor der Datenbank (z. B. Redis) und senkt so Latenz und DB-Last. Aber nicht alle Daten eignen sich zum Cachen, und falsche Invalidierung birgt das Risiko veralteter/falscher Daten. Dieser Baum prüft zuerst, ob du wirklich einen Cache brauchst, hilft dann je nach Lese-/Schreibmuster bei der Wahl zwischen Cache-Aside, Read-Through, Write-Through und Write-Behind und behandelt die Vermeidung von Stampedes.

Wie sieht deine Workload aus: leseintensiv oder schreibintensiv?

Ein Cache lohnt sich am meisten, wenn dieselben Daten oft gelesen werden (leseintensiv) und sich selten ändern. Bestimme zuerst das Gesamtmuster: Werden die Daten viel gelesen und selten geändert, werden sie ständig aktualisiert, oder bist du unsicher, ob sich ein Cache lohnt?

• Sehr leseintensiv, Daten ändern sich relativ selten
• Auch viele Schreibvorgänge; geschriebene Daten werden sofort/oft gelesen
• Nicht sicher; brauche ich wirklich einen Cache?

Wer soll für das Befüllen des Cache zuständig sein?

In einem leseintensiven Szenario ist die zentrale Wahl, wer den Cache befüllt. Soll deine Anwendung den Cache explizit verwalten und selbst auf die DB zurückgreifen (hohe Flexibilität), oder soll die Cache-Schicht bei einem Miss die Daten aus der zugrunde liegenden DB holen und transparent zurückgeben?

• Die Anwendung soll ihn explizit verwalten; ich will Flexibilität und Kontrolle
• Die Cache-Schicht soll bei einem Miss aus der DB laden (transparent)

Hat beim Schreiben Konsistenz oder Schreibgeschwindigkeit Vorrang?

Bei vielen Schreibvorgängen musst du entscheiden, wie konsistent geschriebene Daten zwischen Cache und DB sein sollen. Sollen Cache und DB bei jedem Schreiben gemeinsam aktualisiert werden, um Konsistenz zu garantieren (etwas langsameres Schreiben), oder sollen Schreibvorgänge zuerst in den Cache gehen und asynchron im Hintergrund auf die DB angewendet werden (sehr schnelles Schreiben, aber Verlustrisiko)?

• Konsistenz zählt; Lesevorgänge müssen immer aktuell sein
• Schreibgeschwindigkeit ist kritisch; leicht verzögerte Konsistenz und Verlustrisiko sind akzeptabel

Empfehlung: vorerst keinen Cache hinzufügen

Ein Cache ist nicht kostenlos: Er bringt ein Konsistenzproblem (veraltete Daten), zusätzliche Infrastruktur und Invalidierungskomplexität mit. Ist die Abfrage bereits schnell oder ändern sich die Daten bei jedem Request, bringt ein Cache keinen Nutzen, nur zusätzliche Fehlerquellen.

Empfehlung: Cache-Aside (Lazy Loading)

Bei Cache-Aside prüft die Anwendung zuerst den Cache; fehlen die Daten (Miss), liest sie aus der DB, schreibt sie in den Cache und gibt sie zurück. Das ist das gängigste und flexibelste Muster; der Cache füllt sich nur mit tatsächlich angefragten Daten.

Empfehlung: Read-Through-Cache

Bei Read-Through spricht die Anwendung nur mit dem Cache; bei einem Miss holt die Cache-Schicht selbst die Daten aus der DB und befüllt sich (über einen Provider/Loader). Der Anwendungscode wird einfacher und die Befüllungslogik liegt an einer Stelle.

Empfehlung: Write-Through-Cache

Bei Write-Through geht jeder Schreibvorgang (synchron) sowohl in den Cache als auch in die DB; beide werden gemeinsam aktualisiert. Der Cache hinkt der DB daher nie hinterher, und Lesevorgänge sehen immer aktuelle Daten.

Empfehlung: Write-Behind-Cache (Write-Back)

Bei Write-Behind geht der Schreibvorgang zuerst in den Cache und kehrt sofort zum Benutzer zurück; das Schreiben in die DB erfolgt im Hintergrund asynchron (gebündelt/verzögert). Die Schreibgeschwindigkeit ist am höchsten, es bestehen aber Risiken für Dauerhaftigkeit und Konsistenz.