EMZETT.Caches
Kurz: Zwischenspeicher, die bereits abgerufene Daten für schnelleren, wiederholten Zugriff vorhalten.
Genauer: Caches existieren auf vielen Ebenen — im Browser (HTML/CSS/JS/Bilder), auf DNS-Resolvern (Antworten bis zum Ablauf der TTL), in CDNs oder in der Datenbank-Anbindung einer Anwendung. Ziel ist immer, langsamere Originalquellen (Netzwerk, Datenbank) seltener anfragen zu müssen.
Im Detail
Ein nützliches Bild: Jede Cache-Ebene ist ein Kompromiss zwischen Geschwindigkeit und Aktualität. Je näher ein Cache am Nutzer liegt, desto schneller ist er, aber desto größer ist auch das Risiko, veraltete Daten auszuliefern.
- Browser-Cache: speichert statische Assets (Bilder, CSS, JS) lokal auf dem Gerät des Nutzers — schnellste Ebene, aber pro Gerät getrennt.
- CDN-Cache: ein weltweit verteiltes Netz von Servern, das Inhalte geografisch nah am Nutzer vorhält — z. B. cacht Vercels Edge-Netzwerk statische Seiten von Emzett automatisch.
- DNS-Cache: Resolver merken sich Antworten bis zum Ablauf der TTL, um nicht bei jeder Anfrage erneut die komplette DNS-Kette durchlaufen zu müssen.
- Anwendungs-/Datenbank-Cache: z. B. Redis-Caches für teure Datenbankabfragen.
Jeder dieser Caches kann veraltete (“stale”) Daten liefern, wenn sich die Originaldaten ändern, bevor der Cache aktualisiert wird — das Grundproblem des Cachings ist deshalb weniger das Zwischenspeichern selbst, sondern das rechtzeitige und korrekte Invalidieren. Es gibt dafür zwei grundsätzliche Strategien: zeitbasiertes Ablaufen (der Cache verwirft einen Eintrag automatisch nach einer festen TTL, unabhängig davon, ob sich die Originaldaten wirklich geändert haben) und explizites Invalidieren (die Anwendung sagt dem Cache aktiv “dieser Eintrag ist jetzt ungültig”, z. B. direkt nach einem Datenbank-Update).
Cache-Kohärenz als eigentliches Problem
Bei mehreren Cache-Ebenen gleichzeitig (Browser, CDN, Anwendung) kann ein und dieselbe Anfrage je nach Ebene unterschiedlich aktuelle Antworten liefern — ein User sieht z. B. noch den alten Produktpreis im Browser-Cache, während das CDN längst den neuen ausliefert. HTTP-Header wie Cache-Control und ETag steuern genau das:
Cache-Control: max-age=3600, must-revalidate
ETag: "a1b2c3d4"
max-age gibt an, wie lange ein Client die Antwort ohne erneute Anfrage nutzen darf; must-revalidate zwingt danach zu einer Rückfrage beim Server (statt die veraltete Version einfach weiterzunutzen); ETag ist ein Fingerabdruck des Inhalts, mit dem der Server bei dieser Rückfrage effizient prüfen kann, ob sich überhaupt etwas geändert hat, ohne die komplette Antwort neu zu übertragen (Antwort 304 Not Modified, falls nicht).
Ein bewusst NICHT gecachter Bereich ist bei Emzett z. B. der Warenkorb-Stand — hier wäre selbst ein Cache mit wenigen Sekunden Lebensdauer ein reales Risiko für falsche Bestandsanzeigen.