HTTP-Caching ist in der Theorie unkompliziert: Wenn Cache-Control-, ETag- und TTL-Werte korrekt sind, verwenden Clients und Intermediäre dieselbe Antwort wieder. In der Produktion senden Anwendungen diese Header routinemäßig fehlend, falsch oder zu restriktiv. Das Ergebnis ist, dass cachefähiger Inhalt das Backend unnötigerweise weiterhin trifft.
Selbst bei statischen Assets erodieren kleine URL-Unterschiede die Cache-Effizienz. Dasselbe Produktbild oder dieselbe Katalogseite kann sich wegen Tracking-Parametern wie ein anderes Objekt verhalten. Host, Query-String, Client-Header oder ein falsch konfigurierter Cache-Control-Header senken unnötig die Cache-Trefferquote.
Bei dynamischen Inhalten ist das Problem größer. Derselbe Pfad kann für Mobil- und Desktop-Geräte unterschiedliche Antworten zurückgeben; Preise können nach Land variieren; derselbe Endpoint kann pro Mandant unterschiedliche Daten produzieren. Wenn der Cache-Key diesen Kontext nicht trägt, wird der falsche Inhalt zurückgegeben. Zu viele Header zum Cache-Key hinzufügen und der Cache funktioniert kaum noch.
Externe Cache- oder CDN-Lösungen sind am Internet-Edge nützlich, aber nicht immer für On-Premises-, private API- oder Sovereign-Cloud-Traffic geeignet. Caching auf der ADC-Schicht erfordert typischerweise Konfigurationsdateien, eine benutzerdefinierte Regelsprache oder ein separates Produkt.
TR7 Response-Caching bringt Cache-Profile, bedingte Regeln, dynamische Cache-Keys und Standard-Override-Optionen unter einem einzigen vService-Verwaltungsmodell zusammen.
TR7 verwaltet das Cache-Verhalten durch vier Schichten: Profile, Bedingungen, dynamische Keys und kontrollierte Overrides.
Ein Cache-Profil bündelt Name, Größe, TTL, ETag und Debug-Header-Einstellungen an einem Ort. Dasselbe Profil kann über mehrere vServices geteilt werden, während jeder Service durch seine eigenen Cache-Limits gesteuert wird.
Jede Cache-Regel bindet sich über die FX-Bedingungs-Engine an Pfad, Methode, Header, Cookie oder andere Variablen. Ein öffentlicher Katalog auf demselben Backend kann gecacht werden, während der Warenkorb des Benutzers ausgeschlossen ist — ohne Änderung von Anwendungscode.
Land, Gerätetyp, Mandanten-ID, Benutzersegment oder ein benutzerdefinierter Header können zum Cache-Key hinzugefügt werden. Dieselbe URL teilt sich sauber in separate Cache-Slots pro Kontext auf, wobei Cache-Geschwindigkeit erhalten bleibt und gleichzeitig die Inhaltskorrektheit gestärkt wird.
Host-, Query-String-, Request-Header- und Response-Header-Prüfungen können jeweils bewusst umgangen werden. Falsch konfigurierte Backends oder Tracking-Parameter unterdrücken die Trefferquoten nicht mehr. Operatoren entscheiden explizit, welchen Standard sie wann überschreiben wollen.
Response-Caching macht jedes Verhalten — vom Cache-Profil bis zum dynamischen Key — auf vService-Ebene konfigurierbar.
Jedes Profil wird mit einem Namen, einer maximalen Größe und einem Timeout definiert. Das Größenlimit hält die Cache-Nutzung pro Service unter Kontrolle. Timeout ist in Sekunden, Minuten oder Stunden konfigurierbar. Die Anwendung desselben Profils auf mehrere vServices reduziert operativen Wiederholungsaufwand.
TR7 kann einen Debug-Header zu Antworten hinzufügen, der es einem Entwickler oder Operator ermöglicht, im Browser-Netzwerkbereich zu sehen, ob eine Antwort aus dem Cache oder vom Backend stammt. Kein zusätzliches Log-Tool ist für eine schnelle Überprüfung nötig — es beschleunigt Inbetriebnahme und Abstimmung.
Mehrere Regeln können innerhalb eines einzelnen Cache-Profils definiert werden. Jede Regel wird durch Pfad, Methode, Header, Cookie oder FX-Bedingungen ausgelöst. `/assets/*` kann lange gecacht werden, während `/api/cart` ausgeschlossen ist. Verschiedene Cache-Verhalten innerhalb eines vService werden von einem einzigen Panel aus verwaltet.
ETag kann pro Regel aktiviert werden. Wenn ein Client dasselbe Objekt erneut anfordert und sich der Inhalt nicht geändert hat, erhält er eine Validierungsantwort anstelle des vollständigen Bodys. Dies reduziert den Bandbreitenverbrauch und ist besonders effektiv für statische Assets und selten ändernde API-Antworten.
Wenn dynamisches Caching aktiviert ist, können benutzerdefinierte Variablen zum Cache-Key hinzugefügt werden. Land, Gerätetyp, Mandanten-ID, A/B-Test-Gruppe oder ein aus einem JWT extrahierter Wert können alle Teil des Keys werden. Dieselbe URL trennt sich sauber über Kontexte hinweg. Dies macht Caching für moderne API- und SaaS-Szenarien praktikabel.
Wenn dasselbe Backend identischen Inhalt unter mehreren Domains bereitstellt, kann Host aus dem Cache-Key entfernt werden. Domains wie `a.example` und `b.example` können dann dasselbe gecachte Objekt teilen, was Cache-Duplikation reduziert. Diese Option sollte nur verwendet werden, wenn der Inhalt wirklich geteilt wird.
`utm_source`, Kampagnencodes und Analyse-Parameter können denselben Inhalt als verschiedene Objekte erscheinen lassen. Bei aktivierter Query-Ignorierung werden diese Parameter vom Cache-Key ausgeschlossen. Dieselbe Seite unter mehreren Tracking-Parameter-Varianten trifft das Backend nicht mehr wiederholt. Trefferquoten für öffentliche Inhalte verbessern sich spürbar.
Einige Clients oder Bots fügen Header hinzu, die versuchen, das Caching bei jeder Anfrage zu umgehen. Request-Check-Ignorierung lässt dieses Verhalten bewusst ignorieren. Statische Inhalte und öffentliche API-Antworten werden vor unnötiger Backend-Last geschützt. Diese Einstellung sollte bei sicherheitssensitiven Endpoints sorgfältig angewendet werden.
Ein Backend kann fälschlicherweise `no-store` oder zu restriktive Cache-Header senden. Response-Check-Ignorierung ermöglicht Operatoren, diese Header bewusst zu umgehen. Cache-Vorteile werden ohne Änderung von Anwendungscode erzielt. Diese Option sollte nur für deterministische und sichere Antworten verwendet werden.
Standard-HTTP-Cache-Verhalten konzentriert sich auf GET- und HEAD-Antworten. TR7 ermöglicht es Operatoren, auch POST-Antworten in den Cache-Umfang einzuschließen. Dies ist besonders nützlich, wenn GraphQL-Queries über POST ankommen. Body-Hash oder relevante FX-Variablen können zum Cache-Key hinzugefügt werden, um sichere Trennung zu gewährleisten.
Der Cache wird im Laufzeitspeicher gehalten. Konfigurationsänderungen werden über ein Soft-Reload-Modell angewendet; kein Laufzeit-Invalidierungs-Endpoint wird beansprucht. Das Aktualisieren eines Cache-Profils oder einer Regel aktualisiert das relevante Cache-Verhalten. Wenn das Gerät neu startet, beginnt der Cache wieder leer aufzuwärmen.
Wenn das Cache-Größenlimit erreicht wird, werden die am wenigsten verwendeten oder veralteten Objekte verdrängt. Operatoren müssen einzelne Objekte nicht manuell verwalten. Das Größenlimit verhindert, dass der Cache eines vService andere Services beeinträchtigt. Die Profilgröße kann für große Asset-Kataloge erhöht werden.
Response-Caching sollte zusammen mit Cache-TTL, Objektgröße, Key-Design, dem Invalidierungsmodell und Sicherheitsgrenzen geplant werden.
Die maximale Größe für ein Cache-Profil wird in MB definiert; bis zu 2048 MB pro Profil werden unterstützt. Größere Profile eignen sich für große Asset-Kataloge; ein niedrigeres Limit ist für kleine API-Antwort-Caches ausreichend.
Ein sehr kurzer TTL verursacht Cache-Thrashing und mindert den Caching-Vorteil. TR7 erzwingt ein Minimum von 10 Sekunden, um unnötige Füll-und-Leerzyklen zu verhindern. TTL sollte auf die Aktualisierungshäufigkeit jedes Endpoints abgestimmt werden.
Ein schlecht entworfener Cache-Key kann benutzer- oder mandantenspezifischen Inhalt im falschen Kontext zurückgeben. Wenn eine Differenzierung nach Mandant, Land, Gerätetyp oder Benutzersegment benötigt wird, müssen diese Werte in die dynamischen Cache-Keys aufgenommen werden. Sensitive Endpoints sollten standardmäßig vom Caching ausgeschlossen werden.
Der Cache ist speicherbasiert; er startet leer, wenn das Gerät oder der Service neu startet. Dies eliminiert die Komplexität des persistenten Festplatten-Caches. Der Cache wärmt sich mit der initialen Traffic-Welle wieder auf.
Kein Laufzeit-Invalidierungs-Endpoint wird beansprucht. Das Cache-Verhalten wird durch Bearbeiten von Profilen oder Regeln und Auslösen eines Soft-Reloads verwaltet. Um das Verhalten eines bestimmten Endpoints zu ändern, aktualisieren Sie die relevante Cache-Regel.
Cache-Profil-, Timeout-, Ignore-Optionen und Änderungen an dynamischen Keys sollten im Audit-Log erfasst werden. Wer welches Endpoint-Cache-Verhalten geändert hat, ist sichtbar. Dies ist besonders wichtig für Compliance und Vorfall-Analyse.
Produktseiten und Katalog-APIs werden für einen definierten Zeitraum gecacht. Land wird zum Cache-Key hinzugefügt, sodass Märkte mit unterschiedlichen Preisen oder Lagerbeständen den korrekten Inhalt erhalten.
Nachrichten-, Ankündigungs- oder öffentliche Inhalts-Endpoints können für einige Minuten gecacht werden. Query-Ignorierung verhindert, dass Tracking-Parameter die Trefferquote senken.
Mandanten-ID oder ein benutzerdefinierter Header wird zum Cache-Key hinzugefügt. Derselbe Pfad wird sicher für verschiedene Mandanten zu separaten Cache-Slots geroutet.
Selbst wenn GraphQL-Queries über POST ankommen, können deterministische Queries gecacht werden. Body-Hash oder relevante FX-Variablen werden zum Cache-Key hinzugefügt, um das Risiko zu minimieren, eine falsche Antwort zurückzugeben.
CSS, JS, Bilder und Font-Dateien werden mit einem langen TTL gecacht. Mit aktiviertem ETag überspringen Clients den vollständigen Body-Download, wenn unveränderter Inhalt angefordert wird.
User-Agent-Familie oder Geräteklasse wird zum Cache-Key hinzugefügt. Dieselbe URL wird in separaten Cache-Slots für Mobile und Desktop gehalten.
Cache-Profile, bedingte Regeln, dynamische Keys und RFC-konforme Override-Optionen für Response-Caching. Lassen Sie uns ein Live-Setup auf Ihren eigenen Services durchgehen.