Publiziert: Zuletzt aktualisiert:

Caching und CDN

Tempo entsteht nur, wenn Cache-Eviction beherrscht wird

Caching hält eine fertige Antwort näher beim Anfragenden vor, statt sie jedes Mal neu zu berechnen oder zu übertragen. Das senkt Latenz und Last zugleich. Der schwierige Teil ist nie das Speichern, sondern das Verwerfen: Cache-Invalidierung entscheidet, ob ein schneller Cache auch ein korrekter ist.

Jede zusätzliche Cache-Ebene macht eine Anwendung schneller und gleichzeitig schwerer zu durchschauen. Eine veraltete Antwort aus dem Cache ist aus Sicht des Nutzers ein Fehler, auch wenn sie technisch fehlerfrei ausgeliefert wurde. Diese Seite beschreibt die gestaffelten Cache-Ebenen vom Client bis zur Datenbank, die Rolle von Content Delivery Networks am Netzrand und warum die Invalidierung das eigentliche Problem ist.

Die Cache-Ebenen

Caching ist kein einzelner Ort, sondern eine Kette von Ebenen zwischen Nutzer und Datenquelle. Jede Ebene fängt einen Teil der Anfragen ab, bevor sie die nächste erreicht:

  • Client-Cache. Der Browser hält statische Dateien und HTTP-Antworten lokal vor, gesteuert über Cache-Control, ETag und Last-Modified. Eine Anfrage, die der Browser aus seinem eigenen Cache beantwortet, erreicht das Netzwerk gar nicht erst.
  • Reverse-Proxy- und Edge-Cache. Ein vorgelagerter Proxy wie Varnish oder nginx, oder ein CDN-Knoten, beantwortet wiederkehrende Anfragen vieler Nutzer, ohne die Anwendung zu belasten. Dies ist ein gemeinsamer Cache (shared cache) und unterliegt anderen Regeln als der private Browser-Cache.
  • Anwendungs-Cache. Innerhalb der Anwendung halten In-Memory-Speicher wie Redis oder Memcached berechnete Ergebnisse, Sitzungsdaten oder zusammengesetzte Objekte vor. Diese Ebene entlastet die Datenbank, indem sie teure Berechnungen nicht wiederholt.
  • Datenbank-Cache. Die Datenbank selbst hält Daten- und Indexseiten, Ausführungspläne je nach Datenbank im Arbeitsspeicher (Buffer Pool). Diese Ebene ist meist transparent, aber spürbar, sobald der Arbeitsspeicher knapp wird.

Die Reihenfolge ist bewusst: Ein Treffer (cache hit) auf einer frühen Ebene ist billiger als auf einer späten. Der Browser-Cache spart eine ganze Netzwerkrunde, der Datenbank-Cache nur eine Festplatten-Lesung. Wo diese Ebenen leben und wie sie betrieben werden, beschreibt die Cloud-Native-Architektur, in der zustandslose Dienste den geteilten Cache erst praktikabel machen.

CDN: der Cache am Netzrand

Ein Content Delivery Network verteilt Kopien von Inhalten auf viele geografisch verteilte Knoten (Points of Presence). Eine Anfrage wird zum nächstgelegenen Knoten geleitet, der die Antwort entweder aus seinem Cache liefert oder einmalig vom Ursprungsserver (origin) holt und dann selbst vorhält. Zwei Effekte überlagern sich dabei:

  • Nähe senkt Latenz. Die physische Distanz zwischen Nutzer und Knoten bestimmt die unvermeidbare Mindest-Laufzeit. Ein Knoten in derselben Region spart die Pakete-Reise über Kontinente.
  • Verteilung senkt Last. Der Ursprungsserver sieht nur noch die Anfragen, die kein Knoten beantworten konnte (cache miss). Bei gut zwischenspeicherbaren Inhalten fängt das CDN den Grossteil des Verkehrs ab.

Klassisch waren CDNs auf statische Dateien beschränkt. Moderne CDNs können so konfiguriert werden, dass sie auch dynamische Antworten zwischenspeichern oder Logik am Netzrand ausführen (Edge Computing). Diese Fähigkeiten sind anbieter- und tarifabhängig, kein automatisches Merkmal jedes CDN. Für Inhalte mit hohem Lesezugriff, etwa im Headless E-Commerce, ist die CDN-Ebene oft der grösste einzelne Hebel auf die wahrgenommene Geschwindigkeit.

Das harte Problem: Invalidierung

Einen Wert in einen Cache zu schreiben ist trivial. Die Schwierigkeit liegt darin, ihn zum richtigen Zeitpunkt wieder zu entfernen, bevor er falsch wird, aber nicht so früh, dass der Cache nutzlos wird. Drei Grundstrategien stehen zur Wahl, und sie schliessen einander nicht aus:

  • Ablauf nach Zeit (TTL). Ein Eintrag gilt für eine feste Dauer als frisch und wird danach verworfen oder neu validiert. Einfach, aber ungenau: Bis zum Ablauf kann der Cache veraltet sein, und kurz vor Ablauf wird er unnötig verworfen.
  • Validierung. Statt blind abzulaufen, fragt der Cache mit If-None-Match (gegen den ETag) oder If-Modified-Since beim Ursprung nach, ob sich etwas geändert hat. Hat es das nicht, antwortet der Ursprung mit 304 Not Modified, und die Übertragung des Inhalts entfällt.
  • Aktives Verwerfen (Purge). Beim Schreiben der Daten wird der betroffene Cache-Eintrag gezielt entfernt. CDNs unterstützen dies über Surrogate Keys oder Cache-Tags, mit denen sich zusammengehörige Inhalte in einem Schritt invalidieren lassen, ohne den gesamten Cache zu leeren.

Schwierig wird es, sobald ein zwischengespeicherter Wert aus mehreren Quellen zusammengesetzt ist. Dann muss jede Änderung an einer Quelle wissen, welche abgeleiteten Cache-Einträge sie berührt. Ein Muster wie stale-while-revalidate entschärft den Zielkonflikt: Der Cache darf einen abgelaufenen Wert noch ausliefern und holt parallel im Hintergrund die frische Version, sodass kein Nutzer auf die Neuberechnung wartet. Die Korrektheit bleibt dennoch eine Frage der Disziplin, nicht der Technik allein.

Latenz gegen Konsistenz

Jede Cache-Entscheidung ist ein bewusster Tausch. Wer eine lange TTL setzt, gewinnt Tempo und Lastentlastung, riskiert aber, dass Nutzer veraltete Daten sehen. Wer kurz cacht oder bei jeder Änderung purged, hält die Daten frisch, gibt aber einen Teil des Gewinns wieder her. Die richtige Wahl hängt am Inhalt: Ein Produktbild verträgt Stunden, ein Kontostand keine Sekunde. Der folgende Pfad zeigt, wie eine Anfrage die Ebenen durchläuft und wo sie idealerweise endet:

flowchart TD
    A["Anfrage des Nutzers"] --> B{"Client-Cache frisch?"}
    B -->|ja| Z["Antwort ohne Netzwerk"]
    B -->|nein| C{"Edge- oder Proxy-Cache trifft?"}
    C -->|ja| Y["Antwort vom Netzrand"]
    C -->|nein| D{"Anwendungs-Cache trifft?"}
    D -->|ja| X["Antwort aus In-Memory-Speicher"]
    D -->|nein| E["Datenbank, dann Cache füllen"]
    E --> F["Invalidierung beim nächsten Schreibvorgang"]

Der Diagramm-Pfad macht sichtbar, warum ein Treffer auf einer frühen Ebene wertvoller ist: Er kürzt alle folgenden Schritte ab. Der letzte Knoten ist der entscheidende, denn ohne saubere Invalidierung beim Schreiben liefern alle vorgelagerten Ebenen mit hoher Trefferquote zuverlässig veraltete Daten aus.

Wo Caching kippt

  • Stille Veralterung. Ein zu grosszügiges TTL liefert wochenlang alte Inhalte, ohne dass jemand einen Fehler bemerkt. Der Cache funktioniert technisch, das Ergebnis ist trotzdem falsch.
  • Cache-Stampede. Läuft ein stark nachgefragter Eintrag ab, schlagen alle Anfragen gleichzeitig bis zum Ursprung durch und überlasten ihn. Gegenmittel sind gestaffelte Ablaufzeiten oder eine Sperre, die nur eine Neuberechnung zulässt.
  • Falscher Cache-Schlüssel. Wird ein nutzerspezifischer Inhalt unter einem geteilten Schlüssel zwischengespeichert, sehen Nutzer fremde Daten. Die Trennung von privatem und geteiltem Cache ist hier kein Detail, sondern eine Sicherheitsfrage.
  • Caching als Pflaster. Ein Cache, der eine grundlegend zu langsame Abfrage kaschiert, verschiebt das Problem nur. Fällt der Cache aus, fällt das System. Ob der Cache funktioniert, zeigt erst durchgehende Observability über Trefferquote, Latenz und Ursprungslast.

Kontrolle darüber, wohin Inhalte reisen

Wer ein CDN einsetzt, gibt einen Teil der Kontrolle darüber ab, wo Kopien der eigenen Inhalte liegen: Ein CDN verteilt sie auf Knoten in vielen Ländern. Sobald diese Inhalte Personendaten enthalten, etwa in einer zwischengespeicherten API-Antwort, verlassen diese Daten unter Umständen die Schweiz und die EU, und das revidierte Datenschutzgesetz (revDSG) sowie bei US-Anbietern der US Cloud Act greifen dann auch für Cache-Kopien. Statische, nicht personenbezogene Inhalte sind unkritisch; personenbezogene oder besonders schützenswerte Inhalte gehören entweder nicht in einen global verteilten Cache oder auf einen Anbieter mit kontrollierbaren Standorten. Die Messung, ob die Cache-Ebenen ihre Wirkung tatsächlich entfalten, ist Teil der Leistung Observability und Telemetrie; der betriebliche Unterbau, auf dem geteilte Caches und CDN-Anbindung sauber laufen, gehört zum Platform Engineering und IDP.

Referenzen

Verwandte Themen

KI fragen

Diese Links öffnen externe KI-Dienste, die Unterhaltung und deren Inhalt werden dabei an den jeweiligen Anbieter übertragen.