Caching: dieselbe Antwort, noch einmal gefragt

Du hast einen Client, einen Server und einen Vertrag zwischen ihnen. Sieh jetzt, was der Server wirklich gefragt wird. Eine beliebte Shop-Seite wird tausendmal pro Stunde von tausend verschiedenen Leuten angefragt, und die Antwort ist jedes einzelne Mal identisch. Der Server liest dieselben Zeilen erneut aus der Datenbank, baut dasselbe JSON erneut zusammen und schickt dieselben Bytes — tausendmal, für eine einzige Tatsache, die sich heute Morgen geändert hat. Caching ist die Entscheidung, damit aufzuhören.

Dass Caching funktioniert, liegt nicht an cleverem Speichern. Es liegt an der Form echten Verkehrs: Anfragen wiederholen sich. Ein paar Dinge werden enorm oft angefragt, und die meisten Dinge fast nie. Wenn dieselbe Frage tausendmal ankommt, macht es aus tausend Stück Arbeit ein Stück plus neunhundertneunundneunzig Kopien, die Arbeit einmal zu tun und die Antwort zu behalten. Deshalb scheitert Caching manchmal auch böse: Wenn jede Anfrage wirklich anders ist — eine Seite, die für jeden Nutzer persönlich ist —, gibt es nichts wiederzuverwenden, und ein Cache hängt dem echten Arbeitsschritt nur ein Nachschlagen voran.

Caches gibt es auf mehreren Ebenen, und jede Ebene tauscht Nähe gegen Kontrolle. Die Tabelle unten lohnt sich spaltenweise: Ein Treffer näher am Nutzer ist schneller und billiger, aber eine veraltete Kopie näher am Nutzer ist auch die am schwersten zu korrigierende, weil du die Maschine, auf der sie liegt, nicht mehr kontrollierst.

WHERE IT LIVES        WHO SHARES IT    HIT COST     SIZE      LIFETIME
--------------------  ---------------  -----------  --------  ------------------
browser cache         one user         milliseconds smallest  dies with the tab
CDN edge              one city         tens of ms   large     shared by strangers
application cache     one service      under a ms   medium    lives in RAM
database cache        one query        under a ms   large     lives next to the dataAuf jeder Ebene derselbe Tausch: Je näher die Kopie beim Nutzer liegt, desto schneller der Treffer und desto schwerer zurückzuholen.

Der schwierige Teil hat einen Namen: Invalidierung. Wenn sich der Preis in der Datenbank ändert, ist jede gespeicherte Kopie des alten Preises jetzt eine Lüge, und der Server muss diese Kopien entweder löschen oder verfallen lassen. Das richtig hinzubekommen kostet echte Arbeit. Du kannst nach Zeit verfallen lassen — einfach, und für ein Fenster von Minuten falsch. Du kannst beim Schreiben verfallen lassen — korrekt, und dann muss sich jeder Code, der die Daten ändert, daran erinnern, es dem Cache zu sagen; genau so eine Regel wird bei einer Fehlerbehebung um 2 Uhr nachts vergessen. Es gibt keine kostenlose Option; es gibt nur die Wahl, mit welchem Fehler du leben kannst.

Jeder Cache enthält also eine bewusste Wette: Wie veraltet darf diese Antwort sein? Ein Logo darf ein Jahr alt sein, und niemand merkt es. Ein Produktfoto: eine Stunde. Ein Preis: ein paar Sekunden. Ein Kontostand: null — gar nicht cachen. Merk dir: Aktualität ist eine Produktentscheidung, keine technische. Wer als Entwickler max-age=60 wählt, beantwortet in Wahrheit die Frage "Dürfte ein Kunde einen Preis sehen, der eine Minute alt ist?". Ist die Antwort nein, muss der Cache in dem Moment korrigiert werden, in dem sich der Preis ändert — und das ist ein anderes und teureres Design.