Claude Code Caching-Strategien für echte Anwendungen

Caching ist kein magischer Schalter, der eine Anwendung automatisch schneller macht. In einem echten Produkt speichern HTTP-Header, CDN, Service Worker, Redis und Prozessspeicher jeweils andere Daten für unterschiedliche Zeiträume. Wenn Sie Claude Code nur bitten, “Caching einzubauen”, kann die App zwar schneller wirken, aber alte Preise, falsche Lagerbestände oder sogar private Nutzerdaten ausliefern.

Dieser Leitfaden zeigt eine Strategie, die Sie Claude Code vor der Implementierung geben können. Masa hat sie in einer kleinen Express-App und in einem Content-Site-Workflow getestet. Der größte Effekt kam nicht vom sofortigen Einbau von Redis, sondern von der klaren Entscheidung, welche Schicht welche Daten wie lange besitzen darf.

flowchart LR
  User[Browser] --> Http[HTTP cache]
  Http --> SW[Service worker Cache API]
  SW --> CDN[CDN or edge cache]
  CDN --> App[Node or app server]
  App --> Redis[Redis or app cache]
  App --> DB[(Database)]

Zuerst Entscheidungen treffen

Bevor Claude Code Code schreibt, klären Sie vier Fragen:

1. Welche Nutzer dürfen dieselbe Antwort sehen?
2. Wie alt dürfen die Daten sein, bevor es fachlich gefährlich wird?
3. Welcher Key, welche URL oder welcher Cache-Tag wird nach einem Update gelöscht?
4. Wer führt Rollback oder Purge aus, wenn der Cache falsch ist?

Gehashte JavaScript-, CSS- und Bilddateien können oft lange im Cache bleiben. Rechnungsseiten, Kontoeinstellungen und authentifiziertes HTML gehören nicht in einen Shared Cache. MDNs Leitfaden zu HTTP caching erklärt den Unterschied zwischen privatem Browser-Cache und gemeinsamem Cache wie CDN oder Proxy.

Vergleich der Schichten

Schicht	Geeignet für	TTL-Richtwert	Invalidierung	Häufiger Fehler
Browser HTTP Cache	Bilder, CSS, JS, kurze öffentliche API	1 Minute bis 1 Jahr	Dateiname, ETag, Cache-Control	API bleibt zu lange alt
CDN oder Edge	Produktlisten, Artikel-HTML, OGP-Bilder	30 Sekunden bis 1 Tag	URL-, Tag- oder Deploy-Purge	Login-HTML wird geteilt
Service Worker Cache API	Offline-Seite, App Shell, stabiles JSON	Versionsbasiert	Cache-Name pro Release ändern	Alter Worker liefert alte Bundles
Redis oder App-Cache	DB-Aggregate, externe APIs, Rankings	10 Sekunden bis 1 Stunde	Key-Design, Events, TTL	KEYS blockiert Redis
Prozessspeicher	Konfiguration, kurze Feature-Flag-Kopien	Sekunden bis Minuten	Neustart oder explizites Clear	Instanzen haben unterschiedliche Werte

Legen Sie diese Tabelle in CLAUDE.md ab, damit Claude Code bei neuen Routen dieselben Regeln nutzt. Für Projektregeln hilft CLAUDE.md best practices.

Beispiel 1: HTTP-Cache in Express

Der erste Cache, den man korrigieren sollte, ist oft nicht Redis, sondern der Response-Header. Cache-Control sagt Browsern und CDN, wie lange eine Antwort gespeichert werden darf. Die Direktiven stehen in MDNs Cache-Control header.

Speichern Sie dies als server.js und starten Sie es.

npm install express
node server.js

// server.js
const express = require("express");

const app = express();

function cacheControl(req, res, next) {
  const path = req.path;

  if (path.startsWith("/assets/")) {
    res.set("Cache-Control", "public, max-age=31536000, immutable");
    return next();
  }

  if (path.startsWith("/api/private/")) {
    res.set("Cache-Control", "no-store");
    return next();
  }

  if (path.startsWith("/api/public/")) {
    res.set("Cache-Control", "public, max-age=60, s-maxage=300, stale-while-revalidate=600");
    res.set("Vary", "Accept-Encoding");
    return next();
  }

  res.set("Cache-Control", "no-cache");
  next();
}

app.use(cacheControl);
app.use("/assets", express.static("public/assets"));

app.get("/api/public/products", (_req, res) => {
  res.json({ items: ["book", "template", "consultation"], generatedAt: new Date().toISOString() });
});

app.get("/api/private/me", (_req, res) => {
  res.json({ userId: "demo-user", plan: "team" });
});

app.listen(3000, () => {
  console.log("http://localhost:3000");
});

Die wichtige Designentscheidung ist die Trennung öffentlicher und privater Routen. /api/private/ bekommt no-store, sodass Browser und CDN die Antwort nicht speichern sollen. Öffentliche APIs erhalten eine kurze Browser-TTL und mit s-maxage eine etwas längere CDN-TTL.

Formulieren Sie für Claude Code die Regel explizit: Authentifizierte Antworten müssen no-store verwenden; nur öffentliche API-Routen dürfen s-maxage nutzen.

Beispiel 2: Redis getOrSet Helper

Redis eignet sich für wiederholte Datenbankabfragen und externe API-Aufrufe. Der sichere Standard ist Cache-Aside: zuerst Redis prüfen, bei Miss aus der Quelle laden und den Wert mit TTL speichern.

npm install redis

// cache.js
const { createClient } = require("redis");

const redis = createClient({
  url: process.env.REDIS_URL || "redis://localhost:6379",
});

let connecting;

async function client() {
  if (redis.isOpen) return redis;
  if (!connecting) connecting = redis.connect();
  await connecting;
  return redis;
}

async function getOrSet(key, ttlSeconds, loader) {
  const r = await client();
  const cached = await r.get(key);

  if (cached !== null) {
    return JSON.parse(cached);
  }

  const fresh = await loader();
  await r.set(key, JSON.stringify(fresh), { EX: ttlSeconds });
  return fresh;
}

async function invalidate(keys) {
  const r = await client();
  if (keys.length > 0) {
    await r.del(keys);
  }
}

module.exports = { getOrSet, invalidate };

// products.js
const { getOrSet, invalidate } = require("./cache");

async function loadProductsFromDb() {
  return [
    { id: "p1", name: "Prompt Templates", price: 500 },
    { id: "p2", name: "Claude Code Consultation", price: 15000 },
  ];
}

async function getPublicProducts() {
  return getOrSet("products:list:v1", 300, loadProductsFromDb);
}

async function updateProduct(productId, patch) {
  console.log("update db", productId, patch);
  await invalidate(["products:list:v1", `products:item:${productId}:v1`]);
}

module.exports = { getPublicProducts, updateProduct };

Vermeiden Sie KEYS products:* in Produktion. Mit wachsendem Keyspace kann der Befehl Redis blockieren. Nutzen Sie bekannte Key-Listen, Sets verwandter Keys oder einen Wartungsbefehl auf Basis von SCAN.

Beispiel 3: Versionierung mit Service Worker Cache API

Ein Service Worker kann Browser-Anfragen abfangen. Die Cache API ist nützlich für Offline-Seiten, App Shells und statische Assets. Das Risiko: Wenn der Cache-Name nie geändert wird, kann ein alter Worker nach dem Deploy weiterhin altes JavaScript ausliefern.

// public/sw.js
const CACHE_VERSION = "claude-code-cache-v2026-06-01";
const STATIC_CACHE = `${CACHE_VERSION}:static`;
const PRECACHE_URLS = ["/", "/offline.html", "/assets/app.css"];

self.addEventListener("install", (event) => {
  event.waitUntil(
    caches
      .open(STATIC_CACHE)
      .then((cache) => cache.addAll(PRECACHE_URLS))
      .then(() => self.skipWaiting())
  );
});

self.addEventListener("activate", (event) => {
  event.waitUntil(
    caches
      .keys()
      .then((names) =>
        Promise.all(
          names
            .filter((name) => !name.startsWith(CACHE_VERSION))
            .map((name) => caches.delete(name))
        )
      )
      .then(() => self.clients.claim())
  );
});

self.addEventListener("fetch", (event) => {
  const request = event.request;
  if (request.method !== "GET") return;

  event.respondWith(
    caches.match(request).then((cached) => {
      if (cached) return cached;

      return fetch(request)
        .then((response) => {
          if (response.ok && new URL(request.url).pathname.startsWith("/assets/")) {
            const copy = response.clone();
            caches.open(STATIC_CACHE).then((cache) => cache.put(request, copy));
          }
          return response;
        })
        .catch(() => caches.match("/offline.html"));
    })
  );
});

Registrieren Sie ihn im Client-Einstiegspunkt.

if ("serviceWorker" in navigator) {
  window.addEventListener("load", () => {
    navigator.serviceWorker.register("/sw.js");
  });
}

Geben Sie Claude Code vor, dass der Cache-Name Release-Datum oder Build-ID enthält und alte Caches in activate gelöscht werden.

Beispiel 4: Claude-Code-Prompt für Cache-Audit

Claude Code ist besonders nützlich, wenn es das ganze Repository auditiert statt nur einen Helper zu schreiben. Die offiziellen Claude Code common workflows empfehlen kleine Schleifen aus Recherche, Änderung und Verifikation. Das passt gut zu Cache-Arbeit.

Du auditierst das Cache-Verhalten einer Webanwendung.
Untersuche dieses Repository auf HTTP-Header, CDN-Annahmen, Service Worker, Redis und Prozessspeicher-Caches.

Gib zurück:
1. Daten, die jede Cache-Schicht speichert
2. TTL und Invalidierungsbedingung
3. Risiko, dass persönliche oder authentifizierte Antworten in einen Shared Cache gelangen
4. Konkrete Screens, auf denen stale data sichtbar werden kann
5. Minimalen Fix-Plan und Verifikationsbefehle

Regeln:
- Annahmen klar markieren
- Bestehende Projektmuster befolgen
- Große Refactorings getrennt vorschlagen und nicht sofort anwenden

Dieser Prompt ist wiederverwendbarer Kontext. Speichern Sie die Audit-Checkliste in einer Vorlage oder in CLAUDE.md und geben Sie nur den aktuellen Diff dazu.

Praktische Szenarien

In einem Produktkatalog oder Template-Shop können öffentliche Produktkarten kurz im CDN liegen, während die DB-Liste fünf Minuten in Redis bleibt. Nach einer Änderung löschen Sie den Listen-Key und purgen die betroffene CDN-URL.

In einem Admin-Dashboard können Umsatz, Seitenaufrufe und Conversion-Raten 30 Sekunden bis 5 Minuten gecacht werden. Berechtigungen, persönliche Benachrichtigungen und Rechnungsdaten bleiben private oder no-store.

Bei Docs und Blogs kann Artikel-HTML kurz an der Edge liegen, gehashte Assets lange, und die Offline-Shell vom Service Worker verwaltet werden. Das passt zu contentlastigen Seiten wie ClaudeCodeLab.

Bei externen APIs puffert Redis Rate Limits für Wetter, Wechselkurse, SaaS-Pläne oder Statusfeeds. Lassen Sie Claude Code die offiziellen Bedingungen prüfen, weil manche Anbieter Speicherung einschränken.

Fallstricke

Der gefährlichste Fehler ist authentifiziertes HTML im CDN. Wenn eine Antwort von Cookies abhängt, verwenden Sie standardmäßig private oder no-store. Für CDN-Geschwindigkeit trennen Sie öffentliche Shell und nutzerspezifische Daten.

Fehlende Vary-Header führen ebenfalls zu falschen Antworten. Wenn Sprache, Kompression, Gerät oder Autorisierung die Antwort ändern, trennen Sie die URL oder senden Sie den passenden Vary-Header.

Redis kann unter Cache Stampede leiden, wenn ein beliebter Key abläuft und viele Requests gleichzeitig die Datenbank treffen. Nutzen Sie TTL-Jitter, einen kurzen Lock oder ein stale-while-revalidate-ähnliches Fallback.

Service Worker können gelöschte Dateien weiter ausliefern. Versionieren Sie den Cache, löschen Sie alte Namen in activate, und halten Sie eine Notfallprozedur zum Unregister bereit.

Invalidierungs-Runbook

1. Umfang festlegen: Produkt, Artikel, Nutzer oder gesamte App.
2. Datenbank-Write zuerst abschließen; bei Fehler keinen Cache löschen.
3. Redis mit bekannten Keys, verwandten Sets oder SCAN bereinigen.
4. CDN per URL oder Tag purgen. Vollständiger Purge ist die letzte Option.
5. Service-Worker-Cache-Version erhöhen und alte Caches prüfen.
6. Mit curl -I, DevTools und Redis-Hit-Rate-Logs verifizieren.
7. Im Incident TTL verkürzen oder sensible Routen auf no-store setzen, danach schrittweise zurückkehren.

Machen Sie dieses Runbook zur Definition of Done für Claude Code. Für Teamdisziplin kombinieren Sie es mit Claude Code productivity tips.

Training, Templates und Beratung

Wenn daraus ein wiederholbarer Team-Workflow werden soll, starten Sie mit der ClaudeCodeLab Produkt- und Template-Bibliothek, damit CLAUDE.md, Review-Prompts und Audit-Prompts einheitlich sind. Wenn CDN, Redis, Berechtigungen und Review-Regeln auf ein echtes Repository gemappt werden müssen, nutzen Sie Claude Code Training und Beratung.

Offizielle Referenzen: MDN zu HTTP caching, die Cache API, Cache-Control und Claude Code common workflows.

Nach dem Test der Beispiele stellte Masa fest: Wiederholte Static-Asset-Anfragen gingen zurück, öffentliche API-Antworten wurden mit CDN-orientierten TTLs berechenbarer, und der Redis-Helper getOrSet machte unnötige DB-Lesezugriffe in Logs sichtbar. Der Service Worker zeigte die wichtigste Lektion: Ohne versioniertes Löschen überlebt altes CSS ein Deployment. Der praktische Gewinn ist nicht nur Geschwindigkeit, sondern klar aufzuschreiben, wo jeder Wert alt werden darf.