Caching-Strategien: Redis-, CDN- und HTTP-Caching für Webanwendungen

Caching ist die effektivste Technik zur Verbesserung der Anwendungsleistung. Ein gut konzipierter Cache kann die Datenbanklast um 90 % reduzieren, die Antwortzeiten von 200 ms auf 2 ms verkürzen und jeden Monat Tausende von Dollar an Infrastrukturkosten einsparen. Allerdings ist Caching auch einer der am meisten missverstandenen Bereiche der Softwareentwicklung – Ungültigmachungsfehler führen zu veralteten Daten, Cache-Stampedes bringen Server zum Absturz und schlecht gewählte TTLs verschwenden entweder Speicher oder stellen veraltete Inhalte bereit.

Wichtige Erkenntnisse

• Entwerfen Sie das Caching in Schichten: Browser über CDN über Anwendung (Redis) bis hin zum Datenbankabfrage-Cache – jede Ebene verarbeitet unterschiedliche Dateneigenschaften – Das Redis-Cache-Aside-Muster ist die sicherste Standardeinstellung: Aus dem Cache lesen, auf die Datenbank zurückgreifen, Cache bei Fehlschlag auffüllen
• HTTP-Cache-Header (Cache-Control, ETag, Vary) eliminieren unnötige Anfragen vollständig – die schnellste Anfrage erreicht nie Ihren Server – Die Cache-Invalidierung ist schwieriger als das Caching – verwenden Sie den TTL-basierten Ablauf als primäre Strategie und die ereignisgesteuerte Invalidierung für die Aktualität kritischer Daten

---

Die Cache-Hierarchie

Effektives Caching funktioniert in Schichten, wobei jede Schicht für unterschiedliche Latenz-, Kapazitäts- und Aktualitätsanforderungen optimiert ist.

Schicht 1: Browser-Cache

Der Browser-Cache ist der schnellste und kostengünstigste Cache, da er die Netzwerkanfrage vollständig eliminiert. HTTP-Cache-Control-Header steuern das Browser-Caching-Verhalten.

Legen Sie für statische Assets mit inhaltsgehashten Dateinamen (wie die Build-Ausgabe von Next.js) Cache-Control: public, max-age=31536000, immutable fest. Der Inhalts-Hash im Dateinamen garantiert, dass geänderte Inhalte eine neue URL erhalten, sodass Sie aggressiv zwischenspeichern können, ohne sich Gedanken über veraltete Inhalte machen zu müssen.

Verwenden Sie für HTML-Seiten und API-Antworten kürzere TTLs mit erneuter Validierung: Cache-Control: public, max-age=60, stale-while-revalidate=300. Dadurch werden zwischengespeicherte Inhalte 60 Sekunden lang bereitgestellt, dann im Hintergrund erneut validiert, während veraltete Inhalte bis zu 5 Minuten lang weiterhin bereitgestellt werden.

Schicht 2: CDN-Edge-Cache

Ein CDN speichert Inhalte auf weltweit verteilten Edge-Servern im Cache und reduziert so die Latenz, indem Inhalte von dem Standort bereitgestellt werden, der jedem Benutzer am nächsten liegt. Für eine globale Benutzerbasis reduziert CDN-Caching die durchschnittliche Latenz von 200–500 ms (Ursprungsserver-Roundtrip) auf 10–50 ms (nächste Kante).

Was im CDN zwischengespeichert werden soll:

• Alle statischen Assets (JavaScript, CSS, Bilder, Schriftarten)
• Öffentliche Marketingseiten (mit kurzer TTL für die Aktualität des Inhalts)
• Produktkatalogseiten (5–15 Minuten TTL für E-Commerce)
• API-Antworten für öffentliche Daten (Produktlisten, Blog-Inhalte)

Was NICHT im CDN zwischengespeichert werden sollte:

• Authentifizierte API-Antworten (benutzerspezifische Daten)
• Warenkorb- und Checkout-Seiten
• Admin-Panel-Seiten – Webhook-Endpunkte – Jede Antwort mit Set-Cookie-Headern

Schicht 3: Anwendungscache (Redis)

Redis ermöglicht den Zugriff auf zwischengespeicherte Daten mit Mikrosekunden-Latenz und eignet sich daher ideal für Daten, deren Berechnung teuer ist oder auf die häufig zugegriffen wird. Im Gegensatz zum CDN-Caching kann Redis authentifizierte und benutzerspezifische Daten zwischenspeichern, da Ihre Anwendung den Zugriff steuert.

Schicht 4: Datenbankabfrage-Cache

PostgreSQL unterhält einen Puffercache (shared_buffers), der häufig aufgerufene Tabellen- und Indexseiten im Speicher zwischenspeichert. Auch wenn dies nicht direkt per Abfrage steuerbar ist, sorgt die richtige Konfiguration dafür, dass heiße Daten im Speicher bleiben. Berücksichtigen Sie bei Berichtsabfragen materialisierte Ansichten, die teure Aggregationen vorab berechnen.

---

Redis-Caching-Muster

Redis ist der beliebteste Cache auf Anwendungsebene für Webanwendungen und unterstützt Strings, Hashes, Listen, Sets, sortierte Sets und Streams. Das von Ihnen gewählte Muster bestimmt, wie sich Ihr Cache in Randfällen verhält.

Cache-Aside (Lazy Loading)

Cache-aside ist das sicherste Standardmuster. Die Anwendung prüft zunächst Redis. Bei einem Cache-Treffer werden die zwischengespeicherten Daten zurückgegeben. Bei einem Cache-Fehler wird die Datenbank abgefragt, das Ergebnis mit einer TTL in Redis gespeichert und die Daten zurückgegeben.

Vorteile:

• Nur angeforderte Daten werden zwischengespeichert (keine Speicherverschwendung für ungenutzte Daten)
• Ein Datenbankfehler betrifft nur Cache-Fehler, nicht Cache-Treffer
• Einfach zu implementieren und zu überdenken

Nachteile:

• Die erste Anfrage für jeden Schlüssel trifft immer die Datenbank (Kaltstart) – Veraltete Daten zwischen Datenbankaktualisierung und Cache-Ablauf möglich

Durchschreiben

Beim Write-Through-Caching aktualisiert jeder Datenbankschreibvorgang auch sofort den Cache. Die Anwendung schreibt im selben Vorgang sowohl in die Datenbank als auch in Redis.

Vorteile:

• Der Cache ist immer aktuell – kein veraltetes Datenfenster
• Die Leseleistung ist immer schnell (keine Cache-Fehler nach dem ersten Schreibvorgang)

Nachteile:

• Erhöhte Schreiblatenz (zwei Schreibvorgänge pro Vorgang)
• Cache kann Daten enthalten, die nie gelesen werden (verschwendeter Speicher) – Erfordert eine sorgfältige Fehlerbehandlung, wenn ein Schreibvorgang erfolgreich ist und der andere fehlschlägt

Write-Behind (Write-Back)

Write-Behind-Caching schreibt sofort in Redis, verschiebt den Datenbankschreibvorgang jedoch auf einen Hintergrundprozess. Dies reduziert die Schreiblatenz, birgt jedoch das Risiko eines Datenverlusts, wenn Redis ausfällt, bevor der Datenbankschreibvorgang abgeschlossen ist.

Sparsam verwenden – dieses Muster eignet sich für Analysezähler, Ratenbegrenzung und Sitzungsdaten, bei denen gelegentlicher Datenverlust akzeptabel ist, nicht für Finanztransaktionen oder Bestandszählungen.

Cache-Stampede-Prävention

Ein Cache-Ansturm tritt auf, wenn ein beliebter Cache-Schlüssel abläuft und Hunderte gleichzeitiger Anfragen die Datenbank gleichzeitig abfragen, um sie neu aufzubauen. Dies kann die Datenbank überlasten.

Präventionsstrategien:

1. Stale-while-revalidate – stellt leicht veraltete Daten bereit, während eine Anfrage den Cache im Hintergrund neu aufbaut
2. Mutex-Sperre – Verwenden Sie Redis SETNX, um sicherzustellen, dass nur eine Anfrage den Cache neu aufbaut, während andere warten oder veraltete Daten bereitstellen
3. Probabilistischer früher Ablauf – zufällige Neuberechnung vor TTL-Ablauf, wobei Neuaufbauten über die Zeit verteilt werden, anstatt sie auf den Ablauf zu konzentrieren

---

TTL-Strategiedesign

Time-to-Live-Werte (TTL) bestimmen, wie lange Daten im Cache bleiben. Zu kurz und es kommt zu übermäßig vielen Cache-Fehlern. Zu lange und Sie stellen veraltete Daten bereit.

Gleitende TTL vs. feste TTL

Die feste TTL lässt den Schlüssel zu einem festgelegten Zeitpunkt nach der Erstellung ablaufen. Durch das Verschieben von TTL wird der Ablauf jedes Mal zurückgesetzt, wenn auf den Schlüssel zugegriffen wird. Verwenden Sie eine gleitende TTL für Sitzungsdaten (halten Sie aktive Sitzungen am Leben) und eine feste TTL für Inhaltscaches (stellen Sie eine regelmäßige Aktualisierung von der Quelle sicher).

---

Deep Dive zu HTTP-Cache-Headern

HTTP-Caching ist leistungsstark, weil es auf jeder Ebene funktioniert – Browser, CDN, Proxys und Load Balancer verstehen alle die gleichen Header.

Cache-Kontrollanweisungen

• öffentlich – jeder Cache (Browser, CDN, Proxy) kann die Antwort speichern
• privat – nur der Browser darf zwischenspeichern (nicht CDN oder Proxys) – für authentifizierte Antworten verwenden
• no-cache – die Antwort zwischenspeichern, aber vor der Verwendung erneut beim Server validieren (irreführender Name – es wird zwischengespeichert)
• no-store – überhaupt nicht zwischenspeichern (sensible Daten wie Banking-Seiten)
• max-age=N – Cache ist N Sekunden lang gültig – s-maxage=N – CDN/Proxy-Cache-Dauer (überschreibt das maximale Alter für gemeinsam genutzte Caches)
• stale-while-revalidate=N – stellt veralteten Inhalt N Sekunden lang bereit, während er im Hintergrund erneut validiert wird
• unveränderlich – Inhalte werden sich nie ändern (Verwendung mit inhaltsgehashten URLs)

ETag und bedingte Anfragen

ETags bieten eine inhaltsbasierte Cache-Validierung. Der Server generiert einen Hash des Antwortinhalts und sendet ihn als ETag-Header. Bei nachfolgenden Anfragen sendet der Browser das ETag in einem If-None-Match-Header. Wenn sich der Inhalt nicht geändert hat, antwortet der Server mit 304 Not Modified (kein Text), wodurch Bandbreite gespart wird.

Verwenden Sie ETags für API-Antworten, bei denen sich Inhalte unvorhersehbar ändern und TTL-basiertes Caching entweder zu aggressiv oder zu konservativ wäre.

Header variieren

Der Vary-Header teilt Caches mit, dass die Antwort von bestimmten Anforderungsheadern abhängt. Beispielsweise bedeutet Vary: Accept-Encoding, dass gzip- und Brotli-Versionen separat zwischengespeichert werden. Vary: Accept-Language speichert verschiedene Sprachversionen separat zwischen.

Seien Sie vorsichtig mit Vary – jede eindeutige Kombination unterschiedlicher Header erstellt einen separaten Cache-Eintrag. Vary: Cookie deaktiviert effektiv das Caching, da jeder Benutzer unterschiedliche Cookies hat.

---

Cache-Invalidierungsstrategien

Die Cache-Ungültigmachung ist bekanntermaßen eines der beiden schwierigsten Probleme in der Informatik. Das Ziel besteht darin, zwischengespeicherte Daten zu entfernen oder zu aktualisieren, wenn sich die Quelldaten ändern, ohne dass veraltete Lesevorgänge oder unnötige Cache-Fehler auftreten.

TTL-basierter Ablauf

Die einfachste und zuverlässigste Invalidierungsstrategie. Legen Sie für jeden zwischengespeicherten Schlüssel eine TTL fest und akzeptieren Sie, dass die Daten innerhalb des TTL-Fensters möglicherweise etwas veraltet sind. Für die meisten Anwendungsfälle bietet eine 5-Minuten-TTL eine hervorragende Balance zwischen Frische und Leistung.

Ereignisgesteuerte Invalidierung

Wenn sich ein Datenbankeintrag ändert, veröffentlichen Sie ein Ereignis, das das Löschen des Caches auslöst. Dies sorgt für nahezu sofortige Aktualität, erhöht jedoch die Komplexität und die Fehlermöglichkeiten. Wenn das Ereignis verloren geht (Netzwerkproblem, Warteschlangenfehler), stellt der Cache veraltete Daten bereit, bis TTL abläuft.

Nutzen Sie die ereignisgesteuerte Invalidierung für kritische Daten wie Bestandszahlen und Preise und verlassen Sie sich für alles andere auf TTL.

Tag-basierte Invalidierung

Einige Caching-Systeme unterstützen das Markieren von Cache-Einträgen mit Labels. Wenn Sie ein Tag ungültig machen, werden alle Einträge mit diesem Tag gelöscht. Dies ist nützlich, um alle zwischengespeicherten Daten zu einer bestimmten Entität ungültig zu machen (z. B. alle produktbezogenen Caches, wenn ein Produktkatalog aktualisiert wird).

---

Häufig gestellte Fragen

Wie entscheide ich, was ich zwischenspeichern möchte?

Zwischenspeichern von Daten, die häufig gelesen werden, deren Berechnung teuer ist und die kurzzeitig veraltet sind. Produktkatalogseiten, Benutzerberechtigungen, berechnete Dashboard-Metriken und Konfigurationsdaten sind hervorragende Kandidaten. Einkaufswagen, Bestandszählungen in Echtzeit und Finanztransaktionen sollten im Allgemeinen nicht zwischengespeichert werden oder sehr kurze TTLs mit ereignisgesteuerter Entwertung verwenden.

Was passiert, wenn Redis ausfällt?

Beim Cache-Aside-Muster greift Ihre Anwendung auf die direkte Abfrage der Datenbank zurück. Die Reaktionszeiten erhöhen sich, die Anwendung bleibt jedoch funktionsfähig. Entwerfen Sie Ihre Anwendung so, dass Cache-Fehler ordnungsgemäß verarbeitet werden – Redis sollte eine Leistungsoptimierung und kein Single Point of Failure sein.

Wie viel Speicher sollte ich Redis zuweisen?

Überwachen Sie Ihre Cache-Trefferquote und Speichernutzung. Eine Trefferquote über 95 % bei einer Speicherauslastung unter 80 % weist auf eine gute Dimensionierung hin. Wenn die Trefferquote unter 90 % sinkt, benötigen Sie entweder mehr Speicher oder Ihre TTLs sind zu kurz. Beginnen Sie für die meisten Anwendungen mit 1–2 GB und skalieren Sie basierend auf Überwachungsdaten.

Sollte ich Redis oder Memcached verwenden?

Redis ist für die meisten Anwendungen die bessere Standardwahl. Es unterstützt mehr Datentypen, Persistenzoptionen, Pub/Sub für ereignisgesteuerte Invalidierung und Lua-Skripting für atomare Operationen. Memcached ist für reines Schlüsselwert-Caching im extremen Maßstab einfacher und etwas schneller, aber Redis deckt mehr Anwendungsfälle ab.

Wie verhindere ich die Bereitstellung veralteter Daten nach einer Bereitstellung?

Fügen Sie einen Versionsbezeichner in Ihre Cache-Schlüssel ein (z. B. Präfixschlüssel mit der Bereitstellungsversion oder einer Schemaversion). Bei der Bereitstellung verwendet die neue Version neue Cache-Schlüssel und alte Schlüssel verfallen auf natürliche Weise über TTL. Alternativ können Sie den gesamten Cache bei der Bereitstellung leeren, wenn Ihre Anwendung kalte Caches ordnungsgemäß verarbeitet.

---

Was kommt als nächstes?

Beginnen Sie mit der Implementierung von HTTP-Cache-Headern für Ihre statischen Assets und öffentlichen Seiten – dies sorgt für eine sofortige Leistungsverbesserung ohne Anwendungsänderungen. Fügen Sie dann Redis-Caching für Ihre teuersten Datenbankabfragen und API-Endpunkte hinzu.

Das vollständige Bild zur Leistungsoptimierung finden Sie in unserem Säulenleitfaden zur Skalierung Ihrer Geschäftsplattform. Um die Datenquelle zu optimieren, die Ihren Cache speist, lesen Sie unseren Leitfaden zur Datenbankabfrageoptimierung.

ECOSIRE implementiert Caching-Architekturen für Plattformen, die auf Odoo ERP und Shopify laufen. Kontaktieren Sie unser Team für eine Überprüfung der Caching-Strategie.

---

Veröffentlicht von ECOSIRE – Unterstützung von Unternehmen bei der Skalierung mit KI-gestützten Lösungen in Odoo ERP, Shopify eCommerce und OpenClaw AI.