Das Cache-Aside-Pattern richtig implementieren

1. Was das Cache-Aside-Pattern ist und wann es passt

Beim Cache-Aside-Pattern liegt die gesamte Verantwortung für Lesen, Befüllen und Invalidieren des Caches in der Anwendung, nicht in Redis selbst. Redis kennt in diesem Modell nur einfache Key-Value-Operationen: GET, SET, DEL. Die Anwendung entscheidet bei jedem Zugriff, ob sie den Cache zuerst befragt, und sie entscheidet auch, was bei einem Cache Miss passiert. Diese Trennung macht das Cache-Aside-Pattern zum am weitesten verbreiteten Caching-Muster überhaupt, weil es ohne spezielle Redis-Konfiguration auskommt und in praktisch jeder Anwendungsarchitektur funktioniert.

Das Cache-Aside-Pattern eignet sich besonders für Leselastige Workloads mit ungleichmäßiger Zugriffsverteilung, etwa Produktdetailseiten, Nutzerprofile oder Konfigurationsdaten. Es passt weniger gut, wenn nahezu jeder Datensatz gleich häufig gelesen wird und der Cache dadurch kaum Entlastung bringt, oder wenn Schreiboperationen so häufig sind, dass die Invalidierungslogik zum Flaschenhals wird. In solchen Fällen lohnt sich ein Blick auf Write-Through- oder Write-Back-Strategien als Alternative zum reinen Cache-Aside-Pattern.

2. Lazy Loading: die Grundmechanik in der Anwendungsschicht

Der Kern des Cache-Aside-Patterns ist Lazy Loading: Daten landen erst dann im Cache, wenn sie tatsächlich angefragt wurden, nicht im Voraus. Der Ablauf ist immer derselbe dreistufige Zyklus. Erstens prüft die Anwendung mit GET, ob der Schlüssel in Redis existiert. Zweitens, falls ja, wird der Wert direkt zurückgegeben, ohne die Datenbank zu berühren. Drittens, falls nein, liest die Anwendung aus der Datenbank, schreibt das Ergebnis mit SET und einer TTL in Redis und gibt es dann zurück. Dieser Zyklus ist die eigentliche Definition des Cache-Aside-Patterns.

Der Vorteil von Lazy Loading gegenüber Vorab-Befüllung: Es wird ausschließlich Speicher für Daten belegt, die tatsächlich nachgefragt werden. Ein Redis-Server mit begrenztem Arbeitsspeicher füllt sich so mit den wirklich relevanten, häufig gelesenen Datensätzen, während selten angefragte Datensätze nie den Cache belasten. Der Nachteil zeigt sich beim ersten Zugriff: Dieser ist immer langsamer, weil er den vollen Datenbank-Roundtrip durchläuft, bevor der Cache greift, ein Effekt, der als Cold Start bezeichnet wird.

# Lazy Loading manuell nachvollziehen: Schlüssel existiert noch nicht
redis-cli GET product:4711
# (nil)

# Anwendung liest aus MySQL, befüllt Redis mit TTL
redis-cli SET product:4711 '{"id":4711,"name":"Kaffeemaschine","price":89.90}' EX 3600

# Zweiter Zugriff: Cache Hit, kein Datenbankzugriff mehr noetig
redis-cli GET product:4711
# {"id":4711,"name":"Kaffeemaschine","price":89.90}

# TTL pruefen, um Rest-Lebensdauer zu sehen
redis-cli TTL product:4711
# (integer) 3587

3. Read-Through-Logik in PHP implementieren

In der Anwendungsschicht wird das Cache-Aside-Pattern meist als eigene Methode gekapselt, die von überall im Code aufgerufen werden kann, ohne dass Aufrufer wissen müssen, ob die Daten aus Redis oder aus der Datenbank stammen. Diese Kapselung ist wichtig, weil sie verhindert, dass die Cache-Logik über den gesamten Code verstreut wird. Mit Predis lässt sich diese Read-Through-Logik in wenigen Zeilen sauber implementieren, inklusive Serialisierung der Datenstruktur als JSON.

Wichtig bei der Implementierung ist, dass die Methode einen klaren Rückgabewert liefert und nicht stillschweigend null zurückgibt, wenn sowohl Cache als auch Datenbank leer sind. Nur so lässt sich später zwischen einem echten Cache Miss und einem tatsächlich nicht existierenden Datensatz unterscheiden. Der folgende Ausschnitt zeigt eine typische Cache-Aside-Implementierung für ein Produktrepository.

<?php

declare(strict_types=1);

final class ProductCacheRepository
{
    public function __construct(
        private readonly \Predis\Client $redis,
        private readonly ProductDatabaseRepository $database,
        private readonly int $ttlSeconds = 3600
    ) {
    }

    /**
     * Cache-Aside read: check Redis first, fall back to database on miss.
     */
    public function find(int $productId): ?array
    {
        $key = "product:{$productId}";
        $cached = $this->redis->get($key);

        if ($cached !== null) {
            return json_decode($cached, true);
        }

        // Cache miss: load from source of truth
        $product = $this->database->find($productId);

        if ($product === null) {
            return null; // do not cache "not found" without a strategy
        }

        $this->redis->setex($key, $this->ttlSeconds, json_encode($product));

        return $product;
    }
}

4. Cache Misses korrekt behandeln

Ein Cache Miss ist im Cache-Aside-Pattern kein Fehlerfall, sondern ein normaler, erwarteter Ablaufzweig, der aber sauber behandelt werden muss. Das größte Risiko besteht darin, dass viele gleichzeitige Anfragen für denselben Schlüssel bei einem Miss alle parallel die Datenbank treffen, statt dass eine Anfrage den Cache befüllt und die übrigen davon profitieren. Dieses Problem wird als Cache Stampede bezeichnet und lässt sich mit Locking-Mechanismen entschärfen, etwa über SET key value NX EX ttl als verteilte Sperre.

Ein zweiter wichtiger Punkt: Nicht existierende Datensätze sollten ebenfalls im Cache markiert werden, allerdings mit kurzer TTL und einem klaren Sentinel-Wert wie einem leeren JSON-Objekt. Ohne diese Absicherung erzeugt jede Anfrage nach einer nicht existierenden ID wiederholt einen vollen Datenbank-Roundtrip, ein Muster, das als Cache Penetration bekannt ist und gezielt von böswilligen Clients ausgenutzt werden kann, um die Datenbank zu überlasten.

5. Stale Data: TTL-Strategien gegen veraltete Werte

Da das Cache-Aside-Pattern Daten kopiert statt zu referenzieren, existiert zwangsläufig ein Fenster, in dem der Redis-Wert vom Datenbankwert abweicht, genannt Stale Data. Die TTL ist das primäre Werkzeug, um dieses Fenster zu begrenzen: Eine kurze TTL reduziert die maximale Dauer der Inkonsistenz, erhöht aber die Zahl der Cache Misses und damit die Datenbanklast. Eine lange TTL entlastet die Datenbank, verlängert aber das Risiko veralteter Antworten. Die richtige TTL ist immer ein Kompromiss, der von der Änderungsfrequenz der jeweiligen Daten abhängt.

Für Daten mit unterschiedlicher Volatilität lohnt sich eine differenzierte TTL-Strategie statt einer globalen Konstante: Produktpreise, die sich mehrmals täglich ändern können, brauchen eine kürzere TTL als statische Produktbeschreibungen. Ergänzend hilft ein Jitter, also eine kleine zufällige Abweichung von der Basis-TTL, um zu verhindern, dass viele Schlüssel gleichzeitig ablaufen und dadurch eine Welle gleichzeitiger Cache Misses auslösen.

6. Invalidierung bei Schreiboperationen

Neben der TTL ist die aktive Invalidierung das zweite Werkzeug gegen Stale Data im Cache-Aside-Pattern. Bei jeder Schreiboperation, die einen zwischengespeicherten Datensatz verändert, muss die Anwendung den passenden Redis-Schlüssel explizit mit DEL entfernen, nachdem die Datenbanktransaktion committet wurde. Die Reihenfolge ist entscheidend: Wird zuerst der Cache gelöscht und schlägt danach die Datenbankschreibung fehl, entsteht ein inkonsistenter Zustand, in dem der nächste Leser die alten Daten erneut in den Cache lädt.

Bei komplexen Datenmodellen mit mehreren abhängigen Cache-Einträgen, etwa einer Produktliste und einzelnen Produktdetails, muss die Invalidierung alle betroffenen Schlüssel erfassen. Ein bewährtes Cache-Aside-Pattern dafür ist die Verwendung von Namensräumen mit einer Versionsnummer als Teil des Schlüssels, sodass ein einzelnes Inkrementieren der Version alle davon abhängigen Schlüssel implizit ungültig macht, ohne dass jeder einzelne Schlüssel bekannt sein muss.

# Direkte Invalidierung nach erfolgreichem Datenbank-Commit
redis-cli DEL product:4711

# Versionierter Namensraum: Version einmal inkrementieren statt
# einzelne Schluessel zu loeschen
redis-cli INCR product:version
# (integer) 8

# Alle nachfolgenden Cache-Aside-Schluessel nutzen die aktuelle Version
redis-cli SET "product:v8:4711" '{"id":4711,"price":94.90}' EX 3600

7. Fehlerbehandlung, wenn Redis nicht erreichbar ist

Ein robustes Cache-Aside-Pattern behandelt Redis als optionale Beschleunigung, niemals als harte Abhängigkeit. Fällt die Redis-Verbindung aus, muss die Anwendung transparent auf die Datenbank zurückfallen, statt einen Fehler an den Nutzer auszugeben. In PHP bedeutet das, jeden Redis-Aufruf in try-catch-Blöcke einzubetten und Verbindungsfehler explizit abzufangen, ohne dass die Ausnahme bis zum Controller durchreicht.

Wichtig ist zusätzlich ein kurzes Verbindungs-Timeout, damit ein nicht erreichbarer Redis-Server die Antwortzeit der Anwendung nicht durch lange Wartezeiten dominiert. Ein Timeout von 100 bis 200 Millisekunden ist für die meisten Webanwendungen ein sinnvoller Ausgangswert, deutlich unter der Zeit, die ein Nutzer als spürbare Verzögerung wahrnimmt.

<?php

declare(strict_types=1);

final class ResilientCacheAsideRepository
{
    public function __construct(
        private readonly \Predis\Client $redis,
        private readonly ProductDatabaseRepository $database
    ) {
    }

    /**
     * Cache-Aside read with graceful degradation on Redis failure.
     */
    public function find(int $productId): ?array
    {
        $key = "product:{$productId}";

        try {
            $cached = $this->redis->get($key);
            if ($cached !== null) {
                return json_decode($cached, true);
            }
        } catch (\Predis\Connection\ConnectionException $e) {
            // Redis unreachable: log and fall through to database
            error_log("Redis unavailable, falling back: " . $e->getMessage());
        }

        $product = $this->database->find($productId);

        if ($product !== null) {
            try {
                $this->redis->setex($key, 3600, json_encode($product));
            } catch (\Predis\Connection\ConnectionException $e) {
                // Cache write failure is non-fatal for a read path
                error_log("Redis write failed: " . $e->getMessage());
            }
        }

        return $product;
    }
}

8. Hit-Rate und Latenz beobachten

Ein Cache-Aside-Pattern ohne Monitoring ist eine Blackbox. Die zentrale Kennzahl ist die Hit-Rate, das Verhältnis von Cache Hits zu allen Anfragen, die Redis über INFO stats direkt liefert. Eine Hit-Rate deutlich unter 80 Prozent bei einem Lesehäufig genutzten Datensatz deutet meist auf eine zu kurze TTL, eine zu grobe Schlüsselstruktur oder auf zu viel Invalidierung hin.

Neben der Hit-Rate lohnt sich die Beobachtung der Antwortzeitverteilung, getrennt nach Cache Hit und Cache Miss. Ein typisches Muster: Cache Hits liegen im niedrigen einstelligen Millisekundenbereich, während Cache Misses durch den Datenbankzugriff um den Faktor 10 bis 50 langsamer sind. Diese Differenz zeigt konkret, wie viel Latenz das Cache-Aside-Pattern tatsächlich einspart und rechtfertigt den zusätzlichen Implementierungsaufwand.

# Hit-Rate aus Redis-Statistiken berechnen
redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses"
# keyspace_hits:184920
# keyspace_misses:21044

# Hit-Rate = hits / (hits + misses)
# 184920 / (184920 + 21044) = 89.8 %

# Langsame Kommandos identifizieren (Latenz-Ausreisser)
redis-cli --latency-history -i 5

# Aktuell verwendeten Speicher je Keyspace pruefen
redis-cli INFO keyspace

9. Cache-Aside im Vergleich mit anderen Patterns

Das Cache-Aside-Pattern ist nicht die einzige Möglichkeit, Redis vor eine Datenbank zu schalten. Die Wahl zwischen den Mustern hängt vom Verhältnis zwischen Lese- und Schreiblast sowie von der Toleranz gegenüber Stale Data ab.

In der Praxis wird das Cache-Aside-Pattern meist mit einer moderaten TTL kombiniert, während konsistenzkritische Felder gezielt per Write-Through aktuell gehalten werden. Diese Kombination nutzt die Einfachheit des Cache-Aside-Patterns für den Großteil der Daten und reserviert den höheren Implementierungsaufwand anderer Muster für die wenigen Felder, bei denen Stale Data tatsächlich ein Problem darstellt.

10. Zusammenfassung

Das Cache-Aside-Pattern verlagert die Kontrolle über Caching bewusst in die Anwendung: Lazy Loading befüllt Redis nur mit tatsächlich angefragten Daten, TTL-Werte begrenzen das Fenster für Stale Data, und aktive Invalidierung hält kritische Schlüssel nach Schreiboperationen aktuell. Ein robustes Cache-Aside-Pattern behandelt Redis konsequent als optionale Beschleunigung mit Fallback auf die Datenbank, niemals als harte Abhängigkeit, die bei Ausfall die gesamte Anwendung lahmlegt.

Wer das Cache-Aside-Pattern produktiv einsetzt, sollte von Anfang an Monitoring für Hit-Rate und Latenzverteilung einplanen, Cache Stampede durch Locking-Mechanismen absichern und Cache Penetration durch das Zwischenspeichern von Negativergebnissen verhindern. Diese drei Ergänzungen unterscheiden ein produktionsreifes Cache-Aside-Pattern von einer naiven Implementierung, die unter realer Last schnell an ihre Grenzen stößt.

11. FAQ: Cache-Aside-Pattern richtig implementieren