Cache-Invalidierungsstrategien im Vergleich

1. Die zwei harten Probleme der Informatik

Das Zitat "es gibt nur zwei schwierige Probleme in der Informatik: Cache-Invalidierung und die Benennung von Dingen" trifft einen wahren Kern, weil Cache-Invalidierung kein technisches, sondern ein semantisches Problem ist. Ein Cache speichert eine Kopie von Daten, die sich an der Quelle jederzeit aendern koennen, und die zentrale Frage lautet: woher weiss der Cache, dass seine Kopie veraltet ist, ohne bei jeder Anfrage die Quelle selbst zu befragen, was den Cache ueberfluessig machen wuerde?

Jede Antwort auf diese Frage ist ein Kompromiss. TTL-basierte Cache-Invalidierung akzeptiert temporaere Inkonsistenz zugunsten von Einfachheit. Explizite Invalidierung beim Schreiben strebt sofortige Konsistenz an, erfordert aber, dass jeder Schreibpfad die betroffenen Cache-Eintraege kennt. Tag-basierte Invalidierung loest das Problem der verstreuten Abhaengigkeiten, fuehrt aber zusaetzliche Indexstrukturen ein. Redis bietet fuer alle drei Ansaetze die noetigen Primitive, aber die Wahl der Strategie bleibt eine Architekturentscheidung, die Redis selbst nicht abnehmen kann.

Dieser Artikel vergleicht die drei Hauptstrategien fuer Cache-Invalidierung mit Redis im Detail, behandelt das Thundering-Herd-Problem bei gleichzeitigem Cache-Miss vieler Clients, und liefert am Ende eine praktische Entscheidungshilfe fuer die Wahl der richtigen Strategie im jeweiligen Anwendungsfall.

2. TTL-basierte Invalidierung

Die einfachste Form der Cache-Invalidierung setzt beim Schreiben eines Cache-Eintrags eine feste Lebensdauer, nach deren Ablauf Redis den Eintrag automatisch entfernt. Der naechste Lesezugriff erzeugt dann einen Cache-Miss, laedt die aktuellen Daten aus der Quelle und schreibt sie mit neuer TTL zurueck in den Cache. Dieser Ansatz erfordert keinerlei Koordination zwischen Lese- und Schreibpfaden, was ihn zur mit Abstand einfachsten Form der Invalidierung macht und erklaert, warum TTL in der Praxis die mit Abstand haeufigste Strategie ist.

Der Nachteil liegt in der garantierten temporaeren Inkonsistenz: zwischen einer Datenaenderung an der Quelle und dem naechsten TTL-Ablauf liefert der Cache veraltete Daten aus, im schlimmsten Fall fuer die gesamte TTL-Dauer. Fuer Daten mit geringer Aenderungsfrequenz oder geringer Konsistenzanforderung, etwa einen Produktkatalog, der sich mehrmals taeglich aendert, ist eine TTL von wenigen Minuten meist voellig ausreichend. Fuer Daten mit hoher Konsistenzanforderung, etwa einen Kontostand, ist reine TTL-basierte Cache-Invalidierung ungeeignet und muss durch explizite Invalidierung ergaenzt werden.

# TTL-based caching: simple, no write-path coordination needed
redis-cli> SET product:4711 '{"name":"Widget","price":29.99}' EX 300
OK

# After 5 minutes the key disappears automatically
redis-cli> TTL product:4711
(integer) 287

# Cache miss after expiry triggers a fresh read from the source
redis-cli> GET product:4711
(nil)

3. Explizite Invalidierung beim Schreiben

Bei expliziter Cache-Invalidierung loescht oder aktualisiert der Schreibpfad selbst den betroffenen Cache-Eintrag, sobald sich die zugrunde liegenden Daten aendern. Im Cache-Aside-Muster passiert das typischerweise per DEL direkt nach dem erfolgreichen Schreiben in die primaere Datenquelle: die Anwendung aktualisiert die Datenbank, loescht danach den zugehoerigen Redis-Schluessel, und der naechste Lesezugriff fuellt den Cache mit den frischen Daten. Diese Strategie liefert nahezu sofortige Konsistenz, weil die Verzoegerung nur die kurze Zeitspanne zwischen Datenbankschreibvorgang und Cache-Loeschung umfasst.

Die Herausforderung liegt darin, dass jeder Codepfad, der Daten aendert, die betroffenen Cache-Schluessel kennen und korrekt invalidieren muss. Bei einem einzelnen Entity mit einem einzelnen Cache-Schluessel ist das trivial, bei komplexen Datenmodellen mit mehreren abgeleiteten oder aggregierten Cache-Eintraegen wird es schnell unuebersichtlich, weil das Aendern eines Datensatzes theoretisch dutzende Cache-Eintraege ungueltig machen kann, etwa Listenansichten, Aggregationen und Suchergebnisse. Wird auch nur ein betroffener Schluessel vergessen, entsteht ein stiller Konsistenzfehler, der oft erst durch Nutzerbeschwerden auffaellt.

<?php
declare(strict_types=1);

final class ProductRepository
{
    public function __construct(
        private readonly \PDO $db,
        private readonly \Redis $redis
    ) {
    }

    /**
     * Updates a product and explicitly invalidates the affected
     * cache entries: the single product and any listing pages.
     */
    public function update(int $productId, array $data): void
    {
        $stmt = $this->db->prepare('UPDATE products SET name = :name, price = :price WHERE id = :id');
        $stmt->execute(['name' => $data['name'], 'price' => $data['price'], 'id' => $productId]);

        // Explicit invalidation on write: delete the single entity cache
        $this->redis->del("product:{$productId}");

        // Also invalidate list caches that embed this product's data
        $this->redis->del('product-list:featured');
        $this->redis->del("product-list:category:{$data['category_id']}");
    }
}

4. Tag-basierte Invalidierung

Tag-basierte Cache-Invalidierung loest genau das Problem verstreuter Abhaengigkeiten, das explizite Invalidierung so fehleranfaellig macht. Jeder Cache-Eintrag wird beim Schreiben mit einem oder mehreren Tags verknuepft, etwa product:4711 und category:22, indem die Tag-zu-Schluessel-Zuordnung in einem Redis Set gepflegt wird: SADD tag:category:22 product-list:featured product:4711. Aendert sich ein Datensatz, muss die Anwendung nur noch das betroffene Tag kennen, nicht jeden einzelnen abgeleiteten Cache-Schluessel.

Die Invalidierung selbst liest per SMEMBERS alle mit dem Tag verknuepften Schluessel und loescht sie in einem Batch, meist per Lua-Script fuer Atomaritaet. Dieser Ansatz reduziert die kognitive Last beim Schreiben von Invalidierungslogik erheblich, weil Entwickler nur wissen muessen, welche Tags ein neuer Cache-Eintrag betrifft, nicht welche anderen Cache-Eintraege spaeter davon abhaengen koennten. Der Preis ist zusaetzlicher Speicherverbrauch fuer die Tag-Sets und ein zusaetzlicher Schreibvorgang pro Cache-Eintrag, was fuer die meisten Anwendungen ein guter Tausch gegen deutlich geringeres Risiko vergessener Invalidierungen ist.

-- invalidate_tag.lua
-- Deletes every cache key associated with a given tag
-- KEYS[1] = tag set key, e.g. "tag:category:22"
local keys = redis.call('SMEMBERS', KEYS[1])
for _, key in ipairs(keys) do
  redis.call('DEL', key)
end
redis.call('DEL', KEYS[1])
return #keys

5. Stale-While-Revalidate und Thundering Herd

Ein oft uebersehenes Problem bei jeder Cache-Invalidierung-Strategie ist der Thundering-Herd-Effekt: laeuft ein stark frequentierter Cache-Eintrag ab oder wird explizit invalidiert, treffen gleichzeitig hunderte Anfragen auf einen Cache-Miss und loesen alle parallel dieselbe teure Berechnung oder denselben Datenbankzugriff aus, statt dass nur eine Anfrage die Daten neu laedt. Das kann die Quelle kurzzeitig ueberlasten, gerade in dem Moment, in dem der Cache eigentlich fuer Entlastung sorgen sollte.

Die Loesung ist ein Lock um den Neuaufbau des Cache-Eintrags: die erste Anfrage nach einem Miss erwirbt per SET NX ein kurzes Lock, laedt die Daten, schreibt sie in den Cache und gibt das Lock frei, waehrend alle anderen Anfragen entweder kurz warten und erneut lesen, oder den zuletzt bekannten, mittlerweile abgelaufenen Wert als Stale-While-Revalidate-Antwort ausliefern, waehrend im Hintergrund neu geladen wird. Letzteres liefert Nutzern durchgehend eine Antwort, wenn auch kurzzeitig eine veraltete, statt sie auf eine teure Neuberechnung warten zu lassen, und ist fuer Cache-Invalidierung unter hoher Last die robustere Wahl.

<?php
declare(strict_types=1);

/**
 * Prevents a thundering herd on cache miss by acquiring a short lock
 * before recomputing an expensive value, falling back to a stale
 * cached value for other concurrent callers while it rebuilds.
 */
function getWithHerdProtection(\Redis $redis, string $key, callable $rebuild, int $ttl): mixed
{
    $cached = $redis->get($key);
    if ($cached !== false) {
        return json_decode($cached, true);
    }

    $lockKey = "lock:{$key}";
    if ($redis->set($lockKey, '1', ['NX', 'EX' => 10])) {
        $fresh = $rebuild();
        $redis->setex($key, $ttl, json_encode($fresh));
        $redis->del($lockKey);
        return $fresh;
    }

    // Another process is already rebuilding; serve stale value if any
    $stale = $redis->get("{$key}:stale");
    return $stale !== false ? json_decode($stale, true) : $rebuild();
}

6. Konsistenzmodelle: Cache-Aside versus Write-Behind

Im Cache-Aside-Muster, dem mit Abstand haeufigsten Ansatz, liest die Anwendung zuerst aus dem Cache, laedt bei einem Miss aus der Quelle und schreibt das Ergebnis zurueck in den Cache. Schreibvorgaenge gehen direkt an die Quelle, mit anschliessender expliziter Cache-Invalidierung. Dieses Muster ist einfach zu verstehen und zu debuggen, weil Cache und Quelle klar getrennte Verantwortlichkeiten haben, und ein Cache-Ausfall die Anwendung nicht blockiert, sondern lediglich langsamer macht.

Write-Behind-Caching kehrt die Reihenfolge um: Schreibvorgaenge gehen zuerst in den Cache, der asynchron und verzoegert in die primaere Quelle repliziert wird. Das reduziert Schreiblatenz fuer die Anwendung erheblich, weil die primaere Datenbank nicht mehr im kritischen Pfad jedes Schreibvorgangs liegt, erzeugt aber ein Zeitfenster, in dem der Cache die einzige aktuelle Kopie der Daten ist. Faellt der Cache in diesem Fenster aus, gehen Daten unwiderruflich verloren, weshalb Write-Behind fuer geschaeftskritische Daten nur mit zusaetzlicher Persistenzabsicherung, etwa Redis AOF, vertretbar ist.

7. Strategien im direkten Vergleich

Die Wahl zwischen den drei Hauptstrategien fuer Cache-Invalidierung haengt weniger von technischer Ueberlegenheit als von den tatsaechlichen Anforderungen des Anwendungsfalls ab. TTL-basierte Invalidierung gewinnt bei Einfachheit und eignet sich fuer alles, wo kurzzeitige Inkonsistenz keinen echten Schaden anrichtet. Explizite Invalidierung gewinnt bei Konsistenz fuer Einzelentities mit klar bekannten Abhaengigkeiten. Tag-basierte Invalidierung gewinnt bei komplexen, sich haeufig aendernden Abhaengigkeitsgraphen, wo explizite Invalidierung zu fehleranfaellig waere.

In der Praxis kombinieren die meisten produktiven Systeme alle drei Ansaetze: eine grosszuegige TTL als Sicherheitsnetz gegen vergessene Invalidierungen, explizite Invalidierung fuer die haeufigsten und kritischsten Schreibpfade, und Tag-basierte Invalidierung fuer komplexe Aggregationen und Listenansichten. Diese Kombination aus Cache-Invalidierung-Strategien ist robuster als jede einzelne Strategie fuer sich, weil ein Fehler in einer Ebene durch die anderen Ebenen abgefedert wird.

8. Monitoring und Debugging von Invalidierungs-Bugs

Fehlerhafte Cache-Invalidierung aeussert sich selten als offensichtlicher Fehler, sondern als schwer reproduzierbares Symptom: ein Nutzer sieht veraltete Daten, kann den Fehler aber beim naechsten Versuch nicht mehr reproduzieren, weil der Cache-Eintrag inzwischen abgelaufen ist. Fuer effektives Debugging sollte jeder Cache-Schreibvorgang und jede Invalidierung geloggt werden, idealerweise mit Zeitstempel, betroffenem Schluessel und ausloesendem Ereignis, damit sich im Nachhinein rekonstruieren laesst, wann ein Eintrag zuletzt aktualisiert wurde.

Ein einfaches, aber wirksames Monitoring-Muster ist ein Cache-Hit-Ratio-Dashboard pro Cache-Namespace: faellt die Hit-Ratio fuer einen bestimmten Schluessel-Namespace ploetzlich stark ab, deutet das auf eine zu aggressive Invalidierung hin. Bleibt die Hit-Ratio konstant hoch, obwohl Nutzer veraltete Daten melden, deutet das auf fehlende Invalidierung an einer bestimmten Stelle im Code hin. Redis selbst liefert ueber INFO stats die Kennzahlen keyspace_hits und keyspace_misses, aus denen sich die Hit-Ratio direkt berechnen laesst, ohne zusaetzliche Instrumentierung in der Anwendung.

# Computing cache hit ratio per namespace from Redis stats
redis-cli> INFO stats | grep keyspace
keyspace_hits:8241902
keyspace_misses:193044

# hit_ratio = hits / (hits + misses) = 0.977 -> 97.7%
# A sudden drop for one namespace signals over-aggressive invalidation

redis-cli> MONITOR | grep "product:4711"
# Live stream of every read/write/delete touching this key

9. Praxisentscheidung: welche Strategie wann

Fuer die praktische Entscheidung hilft eine einfache Leitfrage: wie teuer ist eine kurzzeitig veraltete Antwort im Vergleich zu einer fehlenden Antwort oder einer ueberlasteten Quelle? Bei einem Produktkatalog ist eine fuenf Minuten alte Preisanzeige selten kritisch, TTL-basierte Cache-Invalidierung reicht. Bei einem Warenkorb oder Kontostand ist jede Verzoegerung potenziell ein Vertrauens- oder sogar Rechtsproblem, explizite Invalidierung ist Pflicht. Bei einer Suchergebnisseite, die aus vielen einzelnen Produkten aggregiert, ist Tag-basierte Invalidierung fast immer die wartbarere Loesung.

Ein haeufiger Fehler ist, sich fuer das gesamte System auf eine einzige Strategie festzulegen, statt pro Datentyp bewusst zu entscheiden. Cache-Invalidierung ist kein Allzweck-Problem mit einer Allzweck-Loesung, sondern eine Sammlung von Einzelentscheidungen, die jeweils den tatsaechlichen Konsistenzanforderungen und der Aenderungsfrequenz der betroffenen Daten folgen sollten.

10. Zusammenfassung

Cache-Invalidierung mit Redis bietet drei komplementaere Strategien statt einer einzigen richtigen Antwort: TTL-basiert fuer Einfachheit bei tolerabler Verzoegerung, explizit beim Schreiben fuer nahezu sofortige Konsistenz bei klaren Abhaengigkeiten, Tag-basiert fuer wartbare Invalidierung komplexer Abhaengigkeitsgraphen. Die meisten produktiven Systeme kombinieren alle drei, mit TTL als Sicherheitsnetz gegen menschliche Fehler in der expliziten Invalidierungslogik.

Der Thundering-Herd-Effekt bei gleichzeitigem Cache-Miss vieler Clients verdient eigene Aufmerksamkeit unabhaengig von der gewaehlten Invalidierungsstrategie, geloest durch Locks oder Stale-While-Revalidate. Monitoring ueber Hit-Ratio-Kennzahlen macht Cache-Invalidierung-Bugs sichtbar, bevor Nutzer sie melden, und die Entscheidung fuer eine Strategie sollte pro Datentyp getroffen werden, nicht pauschal fuer das gesamte System.

11. FAQ: Cache-Invalidierungsstrategien