Cache-Drift im Shop: alte Preise, fremde Warenkörbe

In fast jeder Beschreibung taucht Caching als Hebel für Ladezeit auf: weniger Datenbankabfragen, schnellere Auslieferung, bessere Werte in der Messung. Das stimmt, greift aber zu kurz. Ein Cache beantwortet die Frage „Was war zuletzt wahr?“ und nicht die Frage „Was ist jetzt wahr?“. In einem Shop sind das zwei verschiedene Dinge, sobald Preise gepflegt, Bestände fortgeschrieben oder Aktionen beendet werden. Wer Caching allein über Tempo steuert, optimiert einen Messwert und nimmt dabei eine Fehlerquelle in Kauf, die in keiner Tempomessung sichtbar wird. Deshalb gehört die Frage nach der Gültigkeit einer Antwort in dieselbe Überwachung wie Erreichbarkeit und Antwortzeit - und nicht in ein getrenntes Kapitel für Fortgeschrittene.

Der zweite Grund, warum Cache-Drift so lange unentdeckt bleibt, ist ihr Auftreten: Sie erzeugt keinen Ausfall. Die Seite lädt, der Warenkorb füllt sich, die Bestellung geht durch. Ein veralteter Preis sieht aus wie ein richtiger Preis, ein veralteter Bestand wie ein vorhandener. Auffällig wird die Sache erst in der Buchhaltung, im Kundendienst oder in einer Beschwerde - also Tage später und weit entfernt von der Ursache. Anders als bei einem Ausfall der Zahlungsstrecke gibt es keinen Zeitpunkt, an dem das System selbst sagt, dass etwas nicht stimmt. Wer die Abweichung finden will, muss sie messen.

Antworten ohne ausdrückliche Ablaufangabe sind der Normalfall, nicht die Ausnahme. Für sie darf ein Cache eine Frist schätzen, und die Norm nennt als typischen Ansatz einen Anteil von 10 % (RFC 9111, Abschnitt 4.2.2) der Zeitspanne seit der letzten Änderung. Das klingt harmlos, ist aber eine Kopplung an eine völlig sachfremde Größe: Eine Seite, die seit dreißig Tagen unverändert ist, bekommt damit eine Frist von rund drei Tagen - unabhängig davon, dass der Preis darauf morgen früh wechselt. Je länger ein Artikel unverändert bleibt, desto länger hält der Speicher an seiner Kopie fest. Der stabile Artikel ist also der gefährlichste.

Die Gegenmaßnahme ist keine Kunst, sondern Disziplin: Jede Antwort, die einen Preis oder einen Bestand trägt, bekommt eine ausdrückliche Frist. Für geteilte Speicher gibt es dafür eine eigene Anweisung, deren Höchstalter das allgemeine Höchstalter und das Ablaufdatum überschreibt (RFC 9111, Abschnitt 5.2.2.10). Damit lässt sich die kurze Frist dort setzen, wo viele Menschen dieselbe Kopie sehen, ohne den Browser des einzelnen Kunden ebenso kurz zu takten. Ebenso wichtig ist die Gegenrichtung: Eine abgelaufene Kopie darf nicht einfach weitergereicht werden, wenn eine ausdrückliche Anweisung das untersagt (RFC 9111, Abschnitt 4.2.4).

Eine Schicht bleibt dabei gern unbemerkt. Für auslieferungsnahe Caches gibt es ein eigenes Kopffeld, und wenn es gesetzt ist, muss die Schicht Cache-Control und Expires in dieser Antwort unbeachtet lassen (RFC 9213, Abschnitt 2.2). Eine sorgfältig gesetzte Frist im Shop ist dann wirkungslos, ohne dass irgendwo ein Widerspruch gemeldet würde. Diese Schicht muss man getrennt messen - mit denselben Werkzeugen, aber von außen, so wie es der Beitrag zur Bilderwartung für kurze Ladezeiten für statische Dateien beschreibt.

Eine Messung braucht drei Zutaten: dieselbe Angabe an mehreren Stellen, einen engen Zeitrahmen und ein Protokoll. Für einen Shop heißt das konkret: den Preis eines Artikels in der Kategorieliste, auf der Detailseite, in der Schnittstelle des Warenkorbs und in der Kasse innerhalb einer Minute abfragen, jeweils den ausgewiesenen Gesamtpreis und die Verfügbarkeit festhalten und zusätzlich notieren, welche Schicht geantwortet hat. Ob die Antwort aus einem Speicher kam, steht im Cache-Status (RFC 9211, Abschnitt 2.1); das Alter der Kopie steht im Age-Feld. Weichen zwei Werte voneinander ab, ist die Drift belegt - mit Zeitstempel, Adresse und Schicht.

Die Messung gehört auf eine Auswahl, nicht auf den ganzen Bestand: die zwanzig umsatzstärksten Artikel, alles mit laufender Aktion, alles mit knappem Bestand. Ein Durchlauf alle fünfzehn Minuten genügt im Alltag; rund um eine Preispflege oder eine Aktion wird der Takt für einige Stunden verkürzt. Wichtig ist der Vergleich mit der Quelle: Der Wert aus der Datenbank ist die Wahrheit, alles andere ist eine Kopie mit Alter. Wer die Messung an die bestehende Überwachung der Antwortzeiten hängt, bekommt beide Bilder in einer Ansicht.

Eine Frist ist die eine Hälfte der Antwort, die gezielte Ungültigkeitserklärung die andere. Ein Cache muss die Zieladresse ungültig machen, sobald er auf eine unsichere Anfrage eine Antwort ohne Fehlerstatus sieht (RFC 9111, Abschnitt 4.4) - eine Bestellung, eine Änderung, eine Löschung. Im Shop kommt eine zweite Ebene dazu: Ändert sich ein Produkt, muss jede zwischengespeicherte Seite fallen, die dieses Produkt zeigt (Shopware-Dokumentation, Cache-Tags). Das sind selten wenige Seiten - ein Artikel steckt in Listen, Suchergebnissen, Empfehlungen und Startseitenblöcken gleichzeitig. Genau deshalb ist die Markierung dieser Beziehungen die empfindlichste Stelle im ganzen Aufbau.

Der vierte Punkt verdient besondere Aufmerksamkeit, weil er nach außen wie ein Cache-Problem aussieht und keines ist. Wird die Ungültigkeitserklärung an eine Warteschlange übergeben und arbeitet der zuständige Prozess nicht, bleibt alles stehen: Die Anwendung meldet die Änderung korrekt, der Speicher erfährt nie davon. Wie sich solche stillen Ausfälle in der Hintergrundverarbeitung überwachen lassen, gehört deshalb in denselben Prüftakt. Führt die Störung zu falschen Preisen im laufenden Verkauf, ist sie ein Fall für den Notfall-Support und nicht für das nächste Wartungsfenster.

Was nicht beschrieben ist, wird nach dem dritten Umbau anders gemacht. Deshalb gehören vier Dinge schriftlich fest: die Frist je Seitenart, die Liste der Antworten, die niemals geteilt werden dürfen, der Auslöser für jede Ungültigkeitserklärung und die Prüfung, die nach jedem Deployment läuft. Diese vier Punkte passen auf eine Seite und ersparen in der Praxis lange Untersuchungen, weil sie aus jeder Abweichung eine Frage nach dem Soll-Zustand machen statt einer Frage nach Meinungen. In einem Wartungsvertrag mit festen Reaktionszeiten sind sie gut aufgehoben, weil sie dort mit Zuständigkeit und Frist verbunden sind.

Im Betrieb ergänzen sich zwei Takte: die laufende Messung, die jede Abweichung binnen Minuten meldet, und die Prüfung im Wartungsfenster, die den Soll-Zustand nach jedem Eingriff wiederherstellt. Wie sich solche Fenster ohne Umsatzausfall legen lassen, zeigt der Beitrag zu Wartungsfenstern im laufenden Verkauf; wie eng Auslieferung und Sichtbarkeit zusammenhängen, der Beitrag zur Überwachung der Indexierbarkeit. Einen Überblick über den Umfang der laufenden Betreuung gibt die Seite zu den Leistungen im Managed Service; wer den Bestand zuerst gemessen haben möchte, findet den Einstieg über die Shopware-Wartung oder direkt über eine Anfrage mit Zugangsdaten zum Shop.