Caching-Strategien mit Claude entwerfen: Invalidierung, Ebenen, Stampede

1. Warum Caching-Design mehr als eine TTL-Zahl ist

In vielen Projekten reduziert sich die Caching-Strategie auf eine einzelne Zahl: eine TTL von fünfzehn Minuten, ohne weitere Überlegung, ob diese Zahl zur tatsächlichen Änderungsfrequenz der Daten passt. Das Ergebnis ist entweder ein Cache, der ständig veraltete Daten ausliefert, weil die TTL zu lang gewählt wurde, oder ein Cache, der kaum Last vom Backend nimmt, weil die TTL aus Vorsicht zu kurz ist. Beides untergräbt den eigentlichen Zweck des Caches.

Claude eignet sich gut, um diese Entscheidung systematisch statt intuitiv zu treffen, wenn man ihm die tatsächliche Änderungsfrequenz der gecachten Daten, die Konsistenzanforderungen der jeweiligen Anwendung und die aktuelle Backend-Last als Kontext liefert. Wichtig bleibt dabei, dass Claude aus diesen Angaben eine begründete Empfehlung ableitet, statt eine Standardzahl wie fünf Minuten pauschal vorzuschlagen.

2. TTL-basierte vs. event-basierte Invalidierung abwägen

TTL-basierte Invalidierung ist einfach zu implementieren, weil kein zusätzlicher Mechanismus zur Erkennung von Datenänderungen nötig ist, sie liefert aber prinzipbedingt für einen Teil der TTL-Dauer veraltete Daten aus. Event-basierte Invalidierung dagegen löscht oder aktualisiert Cache-Einträge genau dann, wenn sich die zugrunde liegenden Daten ändern, was Konsistenz deutlich verbessert, aber zusätzliche Infrastruktur erfordert, etwa einen zuverlässigen Mechanismus, der jede relevante Datenänderung tatsächlich propagiert.

Claude kann beim Abwägen helfen, indem man ihm konkret beschreibt, wie kritisch Konsistenz für den jeweiligen Datentyp ist. Für einen Produktpreis in einem Onlineshop ist event-basierte Invalidierung meist gerechtfertigt, weil ein veralteter Preis zu Vertrauensproblemen führt, während für eine öffentliche Blogartikel-Liste eine großzügige TTL von mehreren Stunden meist ausreicht, weil kurzfristige Verzögerungen dort kaum auffallen.

<?php
declare(strict_types=1);

// Event-basierte Invalidierung: Cache wird beim Speichern des Produkts
// explizit gelöscht, statt auf eine TTL zu warten
final class ProductSavedCacheInvalidator
{
    public function __construct(
        private readonly CacheInterface $cache,
    ) {
    }

    /**
     * Löscht den Produkt-Cache-Eintrag unmittelbar nach dem Speichern.
     *
     * @param int $productId Die ID des geänderten Produkts.
     * @return void
     */
    public function invalidate(int $productId): void
    {
        $this->cache->delete(sprintf('product_%d', $productId));
        $this->cache->delete(sprintf('product_price_%d', $productId));
    }
}

3. Cache-Ebenen sauber trennen: Application, Redis, CDN

Ein häufiger Designfehler ist, alle Caching-Bedürfnisse in eine einzige Ebene zu pressen, obwohl Application-Cache, Redis und CDN sehr unterschiedliche Aufgaben erfüllen. Der In-Process-Application-Cache eignet sich für sehr kurzlebige, häufig wiederverwendete Daten innerhalb einer einzelnen Anfrage, etwa eine bereits geladene Konfiguration. Redis als verteilter Cache eignet sich für Daten, die über mehrere Anwendungsserver hinweg konsistent geteilt werden müssen, etwa Session-Daten oder berechnete Aggregationen. Ein CDN dagegen cached vollständige HTTP-Antworten oder statische Assets möglichst nah am Endnutzer.

Claude kann helfen, für eine konkrete Anwendung die richtige Ebene pro Datentyp zuzuordnen, wenn man ihm die Zugriffsmuster beschreibt: Wie oft wird die Ressource gelesen, wie oft geschrieben, wie viele Anwendungsserver greifen darauf zu, und wie nah am Nutzer darf die Antwort maximal generiert werden. Eine typische Fehlkonfiguration, die Claude im Review erkennen kann, ist ein CDN-Cache auf personalisierten Seiten, der versehentlich Daten eines Nutzers an einen anderen ausliefert.

# Prompt für Claude Code: Cache-Ebene pro Datentyp zuordnen
claude "Hier ist eine Liste unserer 8 wichtigsten gecachten Ressourcen
mit Lese-/Schreibhäufigkeit und Personalisierungsgrad (ressourcen.md).
Ordne jeder Ressource die passende Cache-Ebene zu:
- In-Process Application-Cache
- Redis (verteilt, mehrere App-Server)
- CDN (HTTP-Response-Cache am Edge)
Begründe jede Zuordnung und markiere Ressourcen, die wegen
Personalisierung NICHT im CDN gecacht werden dürfen.

4. Cache Stampede: Wenn viele Requests gleichzeitig nachladen

Ein Cache Stampede entsteht, wenn ein stark nachgefragter Cache-Eintrag gleichzeitig für viele parallele Anfragen abläuft, wodurch alle Anfragen gleichzeitig das Backend treffen, um den Wert neu zu berechnen, statt dass nur eine einzige Anfrage die Neuberechnung übernimmt. Bei hohem Traffic kann das Backend durch diesen plötzlichen Lastschub überlastet werden, obwohl der Cache eigentlich genau das verhindern sollte. Claude kann beim Review von Cache-Zugriffscode gezielt danach fragen, ob ein Schutzmechanismus gegen dieses Muster existiert.

Gängige Gegenmaßnahmen, die Claude vorschlagen kann, sind ein Lock-basierter Ansatz, bei dem nur ein Prozess die Neuberechnung übernimmt, während andere den noch leicht veralteten Wert weiterverwenden, sowie probabilistisches Early Expiration, bei dem Einträge zufällig etwas vor ihrer eigentlichen TTL erneuert werden, um synchronisierte Ablaufzeiten über viele Einträge hinweg zu vermeiden. Beide Muster lassen sich mit Claude anhand des konkreten Cache-Zugriffsmusters durchspielen und auf Implementierbarkeit im vorhandenen Stack prüfen.

<?php
declare(strict_types=1);

// Stampede-Schutz mit Lock: nur ein Prozess berechnet neu
final class StampedeSafeCache
{
    public function __construct(
        private readonly CacheInterface $cache,
        private readonly LockFactory $lockFactory,
    ) {
    }

    /**
     * Liest den Cache-Wert; bei Cache-Miss übernimmt nur ein Prozess
     * die Neuberechnung, andere warten kurz oder nutzen den alten Wert.
     *
     * @param string $key Der Cache-Schlüssel.
     * @param callable $compute Callback zur teuren Neuberechnung.
     * @return mixed Der gecachte oder neu berechnete Wert.
     */
    public function getOrCompute(string $key, callable $compute): mixed
    {
        $value = $this->cache->get($key);
        if ($value !== null) {
            return $value;
        }

        $lock = $this->lockFactory->createLock('cache_' . $key, 5);
        if ($lock->acquire()) {
            try {
                $value = $compute();
                $this->cache->set($key, $value, 300);
                return $value;
            } finally {
                $lock->release();
            }
        }

        // Anderer Prozess berechnet bereits, kurz warten und Stale-Wert nutzen
        return $this->cache->get($key . '_stale') ?? $compute();
    }
}

5. Konsistenzprobleme zwischen Cache-Ebenen analysieren

Sobald mehrere Cache-Ebenen gleichzeitig existieren, entsteht ein weiteres Problem: Die Ebenen können auseinanderlaufen, wenn eine Invalidierung nur eine Ebene erreicht, aber nicht die anderen. Ein typisches Beispiel ist ein Redis-Cache, der bei einer Datenänderung korrekt geleert wird, während ein vorgelagertes CDN die alte HTTP-Antwort noch für Stunden weiter ausliefert, weil niemand an die Notwendigkeit einer CDN-Purge-Anfrage gedacht hat.

Claude kann beim Review einer geplanten Cache-Architektur gezielt nach solchen Lücken fragen: Für jede Cache-Ebene sollte explizit dokumentiert sein, welcher Trigger die Invalidierung auslöst und ob dieser Trigger tatsächlich alle Ebenen erreicht. Eine hilfreiche Übung ist, Claude eine Änderungssequenz durchspielen zu lassen, etwa eine Preisänderung an einem Produkt, und für jede beteiligte Cache-Ebene zu prüfen, wann genau sie den neuen Wert ausliefert.

6. Verwandte Muster: Thundering Herd und Negative Caching

Neben dem klassischen Stampede gibt es verwandte Lastmuster, die im Review oft übersehen werden. Thundering Herd beschreibt allgemeiner den Fall, dass viele Prozesse gleichzeitig auf ein Ereignis reagieren, etwa wenn ein Cache-Server neu startet und alle Anwendungsserver gleichzeitig versuchen, ihn erneut zu befüllen. Negative Caching, also das Zwischenspeichern von Nicht-Ergebnissen wie einem 404 auf eine Anfrage nach einer nicht existierenden Ressource, wird dagegen oft ganz vergessen, obwohl wiederholte Anfragen nach nicht existierenden IDs das Backend genauso belasten können wie reguläre Cache-Misses.

Claude kann beim Durchgehen einer Cache-Strategie explizit nach beiden Mustern fragen: Ist ein Cold-Start-Szenario nach einem Redis-Neustart bedacht, und werden negative Ergebnisse mit einer eigenen, meist kürzeren TTL zwischengespeichert. Beide Aspekte werden in der Erstplanung häufig ausgelassen, weil sie erst unter realistischer Last oder nach einem Infrastruktur-Vorfall auffallen.

7. Cache Warming: Vorab-Befüllung nach Deployments und Neustarts

Ein frisch gestarteter Cache-Server oder eine neue Deploy-Version ohne vorgewärmten Cache trifft für die ersten Anfragen unmittelbar auf das Backend, was bei stark frequentierten Ressourcen zu einem kurzzeitigen, aber deutlichen Lastschub führt, der einem Mini-Stampede ähnelt. Cache Warming bedeutet, die wichtigsten Cache-Einträge proaktiv zu befüllen, bevor echter Nutzer-Traffic auf sie trifft, etwa durch ein Skript, das die häufigsten Abfragen direkt nach einem Deployment synthetisch auslöst.

Claude kann helfen, eine Liste priorisierter Cache-Einträge für ein Warming-Skript zu erstellen, wenn man ihm die Zugriffshäufigkeit der wichtigsten Ressourcen vorlegt, und dabei zwischen Einträgen unterscheiden, die sich für synthetisches Vorab-Laden eignen, und solchen, die zu individuell oder zu selten abgefragt werden, um den Aufwand zu rechtfertigen. Nicht jede Anwendung braucht Cache Warming, aber für Ressourcen mit hoher Berechnungskosten und vorhersehbarem Zugriffsmuster lohnt es sich häufig.

8. Eine Review-Checkliste für Caching-Entwürfe

Eine wiederverwendbare Checkliste für Claude-Reviews sollte mindestens folgende Punkte abdecken: Passt die Invalidierungsstrategie zur Konsistenzanforderung des Datentyps, ist jede Cache-Ebene explizit dokumentiert mit Trigger für die Invalidierung, existiert ein Stampede-Schutz für stark nachgefragte Einträge, ist ein Cold-Start-Szenario bedacht, und wird negatives Caching bewusst eingesetzt oder bewusst vermieden. Diese Kriterien lassen sich als festes Prompt-Template speichern und bei jeder neuen Caching-Entscheidung anwenden.

Genauso wichtig wie die Checkliste selbst ist die Disziplin, sie tatsächlich vor der Implementierung anzuwenden, nicht erst nachdem ein Konsistenzproblem in Produktion aufgefallen ist. Ein zehnminütiges Gespräch mit Claude anhand dieser Checkliste kostet deutlich weniger als ein nächtlicher Incident wegen veralteter Preise oder eines überlasteten Backends nach einem Cache-Stampede.

9. Grenzen: Claude kennt nicht die reale Zugriffsverteilung

Claude kann Invalidierungsstrategien durchdenken und typische Fallstricke wie Stampede oder Konsistenzlücken systematisch aufzeigen, kennt aber weder die tatsächliche Zugriffsverteilung auf einzelne Cache-Schlüssel noch das reale Verhältnis von Lese- zu Schreiboperationen im Produktivbetrieb. Ein Hot Key, auf den ein unverhältnismäßig großer Anteil des Traffics entfällt, lässt sich nur mit echten Metriken aus dem Monitoring identifizieren, nicht aus einer theoretischen Beschreibung der Anwendung.

Deshalb sollte jede mit Claude erarbeitete Caching-Strategie nach dem produktiven Rollout mit echten Metriken überprüft werden: Hit-Rate pro Cache-Ebene, tatsächliche Latenzverteilung und die Häufigkeit von Stampede-artigen Lastspitzen. Claude liefert die konzeptionelle Grundlage und das systematische Durchdenken der Trade-offs, die endgültige Feinabstimmung erfolgt anhand der realen Produktionsdaten.

10. Zusammenfassung

11. FAQ: Caching-Strategien mit Claude: Die wichtigsten Fragen