Caching ist kein Performance-Feature

Wenn ein System langsam wird, fällt das Wort früh: „Dann cachen wir das eben." Es klingt wie eine kleine, lokale Maßnahme — ein paar Zeilen, ein Schlüssel, ein Ablauf. In Wahrheit trifft man in diesem Moment eine der folgenreichsten Architekturentscheidungen überhaupt: Man führt eine zweite Kopie der Wahrheit ein und verpflichtet sich, sie mit der ersten in Einklang zu halten. Alles, was danach schwer wird — falsche Daten, geheimnisvolle Bugs, Ausfälle unter Last —, hat hier seinen Ursprung.

Dieser Text behandelt Caching als das, was es ist: eine Entscheidung über Konsistenz, nicht über Geschwindigkeit. Er ist bewusst framework-, datenbank- und cloud-neutral gehalten. Die Prinzipien gelten für einen Browser-Cache ebenso wie für ein CDN, einen In-Memory-Cache im Prozess oder einen verteilten Cache über viele Knoten.

1. Warum Caching missverstanden wird

Das Missverständnis beginnt bei der Kategorie. Caching wird unter „Performance" verbucht, neben Indizes, Kompression und schnelleren Servern. Aber diese Maßnahmen ändern nur, wie schnell dieselbe Wahrheit geliefert wird. Ein Cache ändert etwas anderes: Er liefert eine womöglich veraltete Wahrheit — schnell. Der Gewinn an Latenz wird mit einem Verlust an Aktualität bezahlt. Das ist keine Optimierung im engeren Sinne, sondern ein Tausch.

Der Grund, warum Caching so verlockend wirkt, ist real: Die meisten Systeme lesen weit häufiger, als sie schreiben, und dieselben Daten werden immer wieder angefragt. Einen Wert einmal zu berechnen und vielfach auszuliefern, spart echte Arbeit. Das Problem ist nicht, dass Caching nicht funktioniert — es funktioniert fast zu gut. Es verbirgt so zuverlässig Langsamkeit, dass es auch strukturelle Probleme verdeckt, die man eigentlich lösen müsste.

Daraus folgt eine Haltung, die diesen ganzen Text trägt: Ein Cache ist die Antwort auf ein gemessenes Problem, nicht der Reflex auf ein vermutetes. Bevor man cacht, muss man wissen, was langsam ist und warum. Oft liegt die Ursache in einer fehlenden Datenbankindizierung, einer N+1-Abfrage oder einem Aufruf, der synchron geschieht und asynchron gehört. In diesen Fällen behebt der Cache das Symptom und konserviert die Krankheit.

Trade-off. Ein Cache tauscht Konsistenz und Einfachheit gegen Latenz und Entlastung der Quelle. Beides ist real; keines ist gratis.

Kosten. Jede gecachte Größe verdoppelt die Zahl der Orte, an denen eine Wahrheit existiert. Diese Verdopplung muss jemand pflegen — im Code, im Kopf und im Betrieb. Die eigentliche Kostenstelle ist nicht der Speicher, sondern die dauerhafte Verpflichtung zur Invalidierung.

Wann wir anders entscheiden. Wenn ein Problem sich sauber an der Quelle lösen lässt — ein fehlender Index, eine entkoppelte Berechnung, eine bessere Abfrage —, lösen wir es dort und cachen nicht. Wir greifen erst zum Cache, wenn die Quelle so schnell ist, wie sie sein kann, und die verbleibende Last aus schierer Wiederholung entsteht.

Schema: Der Cache sitzt zwischen Anfrage und Ursprung. Ab dem Moment, in dem er eine Kopie hält, können beide auseinanderlaufen — das ist der Kern jeder Caching-Frage.

2. Was niemals gecacht werden sollte

Vor der Frage, wie man cacht, steht die Frage, was man cachen darf. Manche Daten vertragen Alterung, andere nicht. Die Grenze verläuft dort, wo eine veraltete Antwort nicht nur unschön, sondern falsch oder gefährlich ist.

Nicht gecacht gehören Autorisierungs- und Berechtigungsentscheidungen. Ob jemand etwas darf, muss zum Zeitpunkt der Handlung gelten, nicht zum Zeitpunkt eines früheren Aufrufs. Ein Cache, der „darf" sagt, nachdem das Recht entzogen wurde, ist eine Sicherheitslücke, kein Performance-Gewinn. Ebenso wenig gehören personenbezogene oder mandantengebundene Daten in einen geteilten Cache ohne strikte Trennung nach Identität — die häufigste Ursache dafür, dass ein Nutzer die Daten eines anderen sieht, ist ein Cache-Schlüssel, der die Identität nicht enthält.

Nicht gecacht gehören außerdem Werte, die in dem Moment stimmen müssen, in dem sie gelesen werden: der aktuelle Kontostand vor einer Abbuchung, der verfügbare Bestand im letzten Schritt einer Bestellung, ein Preis, der rechtlich verbindlich zugesichert wird. Für solche Größen ist „fast aktuell" gleichbedeutend mit „falsch".

Trade-off. Die Versuchung ist, auch diese Werte zu cachen, weil sie oft heiß angefragt werden. Der Tausch wäre aber Latenz gegen Korrektheit — und Korrektheit ist nicht verhandelbar, wo Geld, Recht oder Zugriff betroffen sind.

Kosten. Diese Daten an der Quelle schnell zu halten, kostet echte Arbeit: Indizes, schlanke Abfragen, gegebenenfalls ein dediziertes Lesemodell. Diese Kosten trägt man bewusst, statt sie in einen Cache zu verschieben, der Korrektheit gefährdet.

Wann wir anders entscheiden. Man kann die Herleitung solcher Werte cachen, ohne den Wert selbst zu cachen — etwa eine teure Aggregation, deren Ergebnis am Ende noch gegen den Live-Zustand geprüft wird. Dann liegt die Autorität weiter bei der Quelle, und der Cache trägt nur die Vorarbeit.

3. Cache-Invalidierung

Der bekannte Satz, es gebe in der Informatik nur zwei schwere Probleme — Cache-Invalidierung und das Benennen von Dingen —, ist zur Hälfte ernst gemeint. Invalidierung ist schwer, weil sie verlangt, dass ein System weiß, wann eine Kopie ungültig geworden ist, obwohl die Änderung an einem ganz anderen Ort geschah. Es gibt im Kern drei Wege, dieses Wissen zu organisieren.

Der erste ist der Ablauf: Man vertraut der Kopie für eine feste Dauer und wirft sie danach weg. Der zweite ist das aktive Ungültigmachen: Wer die Wahrheit ändert, löscht oder überschreibt gezielt die betroffene Kopie. Der dritte ist die ereignisgetriebene Invalidierung: Änderungen erzeugen Ereignisse, und der Cache reagiert darauf. Die drei schließen sich nicht aus; robuste Systeme kombinieren sie.

Der schwierigste Teil des aktiven Ungültigmachens ist nicht das Löschen selbst, sondern die Vollständigkeit: Jeder Weg, auf dem sich die Wahrheit ändern kann, muss die Kopie ungültig machen. Wird ein Schreibpfad vergessen — ein Import, ein Admin-Werkzeug, ein Hintergrundjob —, bleibt eine falsche Kopie zurück, und der Fehler zeigt sich nur sporadisch. Genau deshalb ist der Ablauf trotz seiner Schwäche so verbreitet: Er ist die einzige Strategie, die auch dann greift, wenn man einen Schreibpfad übersehen hat.

Trade-off. Aktives und ereignisgetriebenes Ungültigmachen kaufen Aktualität mit Kopplung und Vollständigkeitspflicht. Der Ablauf kauft Einfachheit mit garantierter, aber begrenzter Veraltung.

Kosten. Die teuerste Variante ist die ereignisgetriebene: Sie verlangt eine verlässliche Ereignisverteilung und damit einen Teil der Disziplin, die auch verteilte Nachrichtenverarbeitung braucht — inklusive der Frage, was bei einem verlorenen Ereignis passiert.

Wann wir anders entscheiden. Als Grundlinie wählen wir den Ablauf, weil er auch bei unvollständigem Wissen sicher ist. Aktives Ungültigmachen ergänzen wir dort, wo die Schreibpfade überschaubar sind und die Veraltung im Ablauffenster spürbar stört. Ereignisgetrieben werden wir erst, wenn viele unabhängige Schreiber existieren und eine Ereignisinfrastruktur ohnehin vorhanden ist.

4. Cache-Lebensdauern

Die Lebensdauer — die Zeit, für die man einer Kopie vertraut — ist die stellvertretende Größe für die Frage: Wie viel Veraltung verträgt dieser Wert? Sie ist keine technische, sondern eine fachliche Entscheidung, und sie sollte pro Datenart getroffen werden, nicht global.

Eine zu lange Lebensdauer zeigt veraltete Daten und untergräbt das Vertrauen in das System. Eine zu kurze Lebensdauer wirft die Kopie weg, bevor sie sich amortisiert hat, und lässt die Trefferquote so weit sinken, dass der Cache mehr Verwaltung als Nutzen bringt. Zwischen diesen Polen liegt kein universeller Wert; es gibt nur die Frage, ab welcher Alterung der konkrete Wert falsch genug wird, um zu stören.

Zwei Mechanismen mildern den harten Ablauf. Der erste ist die Neuberechnung im Hintergrund, bevor die Kopie abläuft: Der Wert wird erneuert, während noch die alte Kopie ausgeliefert wird, sodass niemand auf die Berechnung wartet. Der zweite ist die Toleranz gegenüber leicht abgelaufenen Kopien im Fehlerfall: Ist die Quelle nicht erreichbar, liefert man bewusst eine veraltete Kopie, statt einen Fehler zu zeigen. Beide verschieben den Kompromiss zugunsten der Verfügbarkeit — und müssen bewusst gewählt werden, weil sie die garantierte Aktualität weiter aufweichen.

Trade-off. Die Lebensdauer tauscht Aktualität gegen Trefferquote und Entlastung. Jede Verlängerung erhöht die Entlastung und die Veraltung zugleich.

Kosten. Neuberechnung im Hintergrund kostet zusätzliche Komplexität und verschiebt Last in die Zeit kurz vor dem Ablauf; ohne Streuung entsteht daraus leicht ein gleichzeitiger Ansturm auf die Quelle (siehe Fehlermodi).

Wann wir anders entscheiden. Für Daten, die selten falsch schaden, wählen wir großzügige Lebensdauern und akzeptieren sichtbare Alterung. Für Daten nahe an Geld oder Recht wählen wir sehr kurze Lebensdauern oder cachen gar nicht. Für teure, aber selten geänderte Aggregationen kombinieren wir eine lange Lebensdauer mit aktivem Ungültigmachen beim Schreiben — lang genug, um zu entlasten, aber sofort korrigiert, wenn sich die Wahrheit ändert.

5. Schichten des Cachings

Caching geschieht selten an einer Stelle. Zwischen dem Nutzer und der Datenquelle liegen mehrere Schichten, und jede kann eine Kopie halten. Sie zu kennen ist wichtig, weil ein Wert in mehreren Schichten zugleich veralten kann und weil die Kontrolle über die Invalidierung von Schicht zu Schicht abnimmt.

Schema: Je näher am Nutzer die Kopie liegt, desto größer der Latenzgewinn — und desto geringer die Kontrolle darüber, sie wieder loszuwerden.

Die Schicht am Client bringt den größten Latenzgewinn, weil die Anfrage das Gerät gar nicht erst verlässt — aber man kann eine dort liegende Kopie praktisch nicht zurückrufen. Deshalb gehören an den Client nur Dinge mit klar begrenzter Lebensdauer und ohne fremde Identität. Die Schicht in der Anwendung ist am leichtesten zu kontrollieren, aber pro Knoten getrennt: In einem System mit mehreren Instanzen hält jede ihre eigene Kopie, und dieselbe Größe kann auf zwei Knoten unterschiedlich alt sein.

Trade-off. Mehr Schichten bedeuten mehr Entlastung und mehr Nähe zum Nutzer, aber auch mehr Orte, an denen dieselbe Wahrheit unterschiedlich altern kann.

Kosten. Jede zusätzliche Schicht multipliziert den Aufwand der Invalidierung und erschwert die Diagnose: Bei einer falschen Antwort muss man wissen, welche Schicht sie geliefert hat.

Wann wir anders entscheiden. Wir cachen bewusst in möglichst wenigen Schichten und wählen die Schicht nach dem Zweck: öffentliche, für alle gleiche Antworten am Rand; teure, interne Berechnungen in der Anwendung. Mehrere Schichten für dieselbe Größe kombinieren wir nur, wenn jede einen eigenen, benannten Zweck hat — nie „zur Sicherheit".

6. Verteilte Caches

Sobald ein System aus mehreren Knoten besteht, reicht der prozesslokale Cache nicht mehr, weil jeder Knoten seine eigene Wahrheit hält. Ein verteilter Cache — ein von allen Knoten geteilter Speicher — löst dieses Problem und schafft ein neues: Der Cache wird selbst zu einer Komponente, die ausfallen, langsam werden und überlastet sein kann. Er ist dann nicht mehr nur eine Beschleunigung, sondern ein Teil des Systems, von dem die Verfügbarkeit abhängt.

Damit verschiebt sich die Frage. Beim lokalen Cache lautete sie: Wie halte ich meine Kopie aktuell? Beim verteilten Cache kommt hinzu: Was passiert, wenn der Cache nicht antwortet? Ein System, das ohne seinen Cache nicht mehr funktioniert, hat die Datenbank nur gegen eine andere, oft weniger dauerhafte Abhängigkeit getauscht. Der verteilte Cache muss deshalb so behandelt werden wie jede andere Netzwerkabhängigkeit: mit Zeitlimits, mit einem definierten Verhalten im Fehlerfall und mit der Annahme, dass er zeitweise weg ist.

Eine zweite Eigenheit ist die Konsistenz zwischen Cache und Quelle unter Nebenläufigkeit. Wenn zwei Knoten gleichzeitig denselben Wert ändern und den Cache aktualisieren, entscheidet die Reihenfolge über das Ergebnis — und die Reihenfolge im Netzwerk ist nicht garantiert. Das Muster „lesen, ändern, in den Cache schreiben" ist ohne zusätzliche Vorkehrung ein Wettlauf. Die verlässlichere Grundform ist, bei einer Änderung die Kopie zu entfernen statt sie zu überschreiben, sodass der nächste Leser sie frisch aus der Quelle holt.

Trade-off. Ein verteilter Cache tauscht die Inkonsistenz zwischen Knoten gegen eine neue, geteilte Abhängigkeit und deren Ausfallrisiko.

Kosten. Man betreibt jetzt ein zusätzliches, zustandsbehaftetes System: Es braucht Speicherplanung, eine Verdrängungsstrategie, Überwachung und einen Plan für den Fall, dass es voll oder weg ist.

Wann wir anders entscheiden. Solange ein System auf einem Knoten läuft oder die Knoten kleine, tolerierbare Abweichungen vertragen, bleiben wir beim lokalen Cache — er ist einfacher und hat keine Netzwerkabhängigkeit. Den verteilten Cache führen wir ein, wenn die Abweichung zwischen Knoten fachlich stört oder wenn die zu cachende Menge zu groß für jeden einzelnen Prozess wird.

7. Fehlermodi

Ein Cache verändert nicht nur das Verhalten im Normalfall, sondern schafft eigene Fehlerbilder, die es ohne ihn nicht gäbe. Sie treten typischerweise unter Last auf — also genau dann, wenn der Cache eigentlich helfen soll.

Der bekannteste ist der gleichzeitige Ansturm nach dem Ablauf, oft „Stampede" genannt: Ein heißer Wert läuft ab, und alle wartenden Anfragen greifen im selben Moment auf die Quelle zu, weil noch keine die neue Kopie geschrieben hat. Der Cache, der die Quelle schützen sollte, verstärkt die Last, statt sie zu dämpfen. Gegenmittel sind eine Sperre, sodass nur eine Anfrage neu berechnet, während die anderen warten oder die alte Kopie erhalten, und das Streuen der Ablaufzeitpunkte, damit nicht viele Werte gleichzeitig verfallen.

Der zweite ist die Anfrage nach etwas, das gar nicht existiert: Fehlt ein Wert an der Quelle, findet ihn der Cache nie, und jede Anfrage schlägt bis zur Quelle durch. Wird dieser Zustand von außen ausgelöst, kann er zur Überlastung führen. Das Gegenmittel ist, auch die Abwesenheit zu cachen — ein kurzlebiger Eintrag „gibt es nicht" —, mit der Vorsicht, dass ein solcher Eintrag das spätere Anlegen des Werts nicht verdeckt.

Der dritte ist der Totalausfall des Caches: Fällt eine geteilte Cache-Schicht aus, trifft die volle Last unvermittelt die Quelle, die auf diese Last nie ausgelegt war. Ein System, das ohne Cache nicht überlebt, hat damit einen Single Point of Failure. Das Gegenmittel liegt nicht im Cache, sondern in der Auslegung der Quelle: Sie muss eine plötzliche Lastspitze zumindest gedrosselt überstehen.

Trade-off. Die Schutzmechanismen gegen diese Fehler — Sperren, Streuung, Negativ-Caching — erhöhen die Komplexität und können neue Grenzfälle einführen.

Kosten. Diese Fehler zeigen sich meist erst unter echter Last und lassen sich schwer nachstellen. Der Preis, sie zu ignorieren, ist ein Ausfall genau im Moment der höchsten Nachfrage.

Wann wir anders entscheiden. Für selten angefragte oder unkritische Werte verzichten wir auf die aufwändigen Schutzmechanismen und akzeptieren im seltenen Ansturm eine kurze Mehrlast. Für heiße, teure Werte bauen wir Sperre und Streuung von Anfang an ein, weil der Stampede dort keine Frage des Ob, sondern des Wann ist.

8. Beobachtbarkeit

Ein Cache, den man nicht messen kann, ist eine Vermutung. Ohne Kennzahlen weiß man weder, ob er hilft, noch, ob er gerade falsche Daten ausliefert. Beobachtbarkeit ist deshalb kein Zusatz, sondern die Voraussetzung dafür, einen Cache überhaupt verantworten zu können.

Die erste Größe ist die Trefferquote — der Anteil der Anfragen, die aus dem Cache bedient werden. Sie sagt, ob der Cache seinen Zweck erfüllt. Eine dauerhaft niedrige Trefferquote bedeutet, dass man die Kosten der Kopie trägt, ohne ihren Nutzen zu ernten, und ist ein Signal, die Lebensdauer, den Schlüsselzuschnitt oder die Entscheidung zu cachen zu überdenken. Die zweite ist die Verdrängungsrate — wie oft Einträge aus Platzmangel entfernt werden —, denn hohe Verdrängung untergräbt die Trefferquote lautlos. Die dritte ist die Latenz des Caches selbst: Ein verteilter Cache, der langsam antwortet, kann teurer sein als die Quelle, die er ersetzen soll.

Schwerer, aber wichtiger ist die Beobachtung der Korrektheit. Trefferquoten sagen nichts darüber, ob die Treffer richtig waren. Deshalb gehört zu einem ernsthaften Cache die Fähigkeit, Alter und Herkunft einer Antwort sichtbar zu machen — aus welcher Schicht sie kam und wie alt die Kopie war —, damit man bei einer falschen Antwort die verantwortliche Schicht findet, statt zu raten.

Trade-off. Messung und Kennzeichnung kosten etwas Rechenzeit und Speicher und fügen dem heißen Pfad Instrumentierung hinzu.

Kosten. Ohne diese Instrumentierung sind Cache-Fehler unter den am schwersten zu diagnostizierenden Problemen überhaupt, weil sie sich als sporadisch falsche Daten ohne Fehlermeldung äußern.

Wann wir anders entscheiden. Für einen kleinen, lokalen Cache mit klar begrenzter Wirkung genügen einfache Trefferzähler. Für jeden geteilten oder verteilten Cache betrachten wir Trefferquote, Verdrängung, Latenz und die Herkunft der Antwort als Pflicht — im Sinne von Observability als Architekturprinzip, nicht als späteres Add-on.

9. Häufige Fehler

Die wiederkehrenden Muster, an denen Caching scheitert — fast alle sind Varianten desselben Fehlers, den Cache für gratis zu halten:

• Cachen, ohne vorher zu messen — das Symptom lindern und die eigentliche Ursache an der Quelle konservieren.
• Berechtigungen, mandantengebundene oder geldnahe Daten cachen und damit Korrektheit gegen Latenz eintauschen, wo das nicht erlaubt ist.
• Die Identität aus dem Cache-Schlüssel weglassen, sodass ein Nutzer die Kopie eines anderen erhält.
• Nur an das Schreiben der Kopie denken, nicht an ihr Ungültigmachen — jeder übersehene Schreibpfad hinterlässt eine falsche Kopie.
• Eine globale Lebensdauer für alles wählen, statt sie pro Datenart an der tolerierbaren Veraltung auszurichten.
• Ablaufzeitpunkte nicht streuen, sodass viele Werte gleichzeitig verfallen und die Quelle im selben Moment treffen.
• Den verteilten Cache wie eine sichere Quelle behandeln — ohne Zeitlimit, ohne definiertes Verhalten bei seinem Ausfall.
• Bei Änderungen die Kopie überschreiben statt sie zu entfernen und damit unter Nebenläufigkeit einen Wettlauf einbauen.
• Die Abwesenheit eines Werts nicht cachen und so wiederholte Fehlanfragen bis zur Quelle durchschlagen lassen.
• Den Cache nicht messen und deshalb weder Nutzen noch Schaden bemerken, bis Nutzer falsche Daten melden.

10. Entscheidungs-Checkliste

Vor der Einführung eines Caches der Reihe nach zu klären:

• Gemessen? Ist belegt, was langsam ist und warum — und ist ausgeschlossen, dass die Ursache an der Quelle (Index, Abfrage, synchroner Aufruf) besser behoben wird?
• Darf dieser Wert altern? Ist eine leicht veraltete Antwort hier harmlos — und liegt der Wert nicht in Berechtigung, Mandantentrennung oder Geldnähe?
• Schlüssel vollständig? Enthält der Cache-Schlüssel alles, was die Antwort unterscheidet, insbesondere die Identität des Nutzers oder Mandanten?
• Invalidierung entschieden? Ist klar, ob per Ablauf, aktiv oder ereignisgetrieben invalidiert wird — und sind bei aktivem Ungültigmachen alle Schreibpfade erfasst?
• Lebensdauer pro Datenart? Ist die Dauer aus der tolerierbaren Veraltung abgeleitet, nicht global gesetzt?
• Schicht bewusst gewählt? Liegt die Kopie in der Schicht, die zum Zweck passt — und nicht in mehreren „zur Sicherheit"?
• Fehlermodi bedacht? Sind Stampede (Sperre, Streuung), Fehlanfragen (Negativ-Caching) und Cache-Ausfall (Quelle übersteht die Lastspitze) behandelt?
• Verteilter Cache als Abhängigkeit? Hat der geteilte Cache Zeitlimit und definiertes Verhalten, wenn er ausfällt?
• Beobachtbar? Werden Trefferquote, Verdrängung, Latenz und die Herkunft/das Alter einer Antwort gemessen?
• Rückbau möglich? Kann der Cache im Zweifel abgeschaltet werden, ohne dass das System stehenbleibt?

Wer diese Fragen nicht sauber beantworten kann, hat kein Performance-Feature, sondern eine zweite Quelle der Wahrheit ohne Plan, sie zu pflegen.

FAQ

Ist Caching nicht der schnellste Weg, ein langsames System zu beschleunigen? Es ist der schnellste Weg, Langsamkeit zu verbergen. Ob das gut ist, hängt von der Ursache ab. Liegt sie an schierer, wiederholter Leselast, ist der Cache die richtige Antwort. Liegt sie an einer fehlenden Indizierung oder einem synchronen Aufruf, konserviert der Cache das Problem und macht es später schwerer auffindbar. Deshalb steht die Messung vor dem Cache.

Warum ist Cache-Invalidierung so schwer? Weil sie verlangt, an einem Ort zu wissen, dass sich an einem anderen etwas geändert hat. Jeder Weg, auf dem sich die Wahrheit ändern kann, muss die Kopie ungültig machen — und es genügt ein übersehener Schreibpfad, damit eine falsche Kopie zurückbleibt. Der Fehler zeigt sich dann nur sporadisch, was ihn besonders zäh macht.

Sollten wir eine globale Lebensdauer festlegen? Nein. Die Lebensdauer ist eine fachliche Aussage darüber, wie viel Veraltung ein bestimmter Wert verträgt, und die ist von Datenart zu Datenart verschieden. Ein globaler Wert ist entweder für die sensiblen Daten zu lang oder für die unkritischen zu kurz — meist beides zugleich.

Überschreiben oder Löschen wir die Kopie bei einer Änderung? Im Zweifel löschen. Überschreiben unter Nebenläufigkeit ist ein Wettlauf: Zwei gleichzeitige Änderungen können den Cache in eine Reihenfolge bringen, die der Quelle widerspricht. Das Entfernen der Kopie zwingt den nächsten Leser, sie frisch zu holen, und ist dadurch robuster — um den Preis eines zusätzlichen Fehlversuchs.

Was passiert, wenn unser verteilter Cache ausfällt? Das muss vor dem Ausfall beantwortet sein. Ein Cache ist eine Netzwerkabhängigkeit: Er braucht ein Zeitlimit und ein definiertes Verhalten, wenn er nicht antwortet — in der Regel: an der Quelle vorbei weiterarbeiten. Ein System, das ohne seinen Cache steht, hat die Datenbank gegen eine weniger dauerhafte Abhängigkeit getauscht.

Ab wann lohnt sich ein verteilter Cache statt eines lokalen? Wenn die Abweichung zwischen den Knoten fachlich stört oder wenn die zu cachende Menge zu groß für jeden einzelnen Prozess wird. Solange ein lokaler Cache genügt, ist er die bessere Wahl, weil er einfacher ist und keine geteilte Ausfallquelle einführt.

Weiterführend

• Software, die in zehn Jahren noch läuft — warum eine zweite Quelle der Wahrheit die Änderbarkeit über die Lebensdauer prägt.
• Queue oder synchrone Verarbeitung und Asynchrone Verarbeitung einführen — die verwandte Frage, Arbeit nicht im Anfragepfad zu tun.
• Idempotenz in verteilten Systemen — warum das Entfernen einer Kopie robuster ist als ihr Überschreiben, ist dieselbe Disziplin der Wiederholbarkeit.
• Observability als Architekturprinzip — ein Cache, den man nicht misst, ist eine Vermutung.

Grundlage ist die Batunet Engineering Method: erst messen, dann entscheiden; für den Fehlerfall entwerfen; in kleinen, umkehrbaren Schritten bauen.

Ein Cache ist geliehene Geschwindigkeit. Man zahlt sie mit Konsistenz zurück — die Frage ist nur, ob bewusst und geplant oder überrascht und im Ausfall.