--- title: "API-Caching bei hohem Traffic mit Redis und Elasticsearch" description: "Erst P95 messen, dann Cache-Aside, passende TTLs, Invalidierung und Schutz vor Cache Stampedes mit Redis und Elasticsearch. Und was Sie nie cachen sollten." canonical: https://sdk.enterprises/de/insights/caching-high-traffic-apis language: de --- # API-Caching bei hohem Traffic mit Redis und Elasticsearch Aktualisiert: 2026-09-25 > Um eine API mit hohem Traffic zu cachen, messen Sie zuerst und setzen dann eine Cache-Aside-Schicht in Redis vor die langsamsten und meistgelesenen Endpoints, mit expliziten TTLs, Invalidierung beim Schreiben und Schutz vor Cache Stampedes. Nutzen Sie Elasticsearch für Suche und gefilterte Listen, mit denen die primäre Datenbank schlecht zurechtkommt, und cachen Sie nutzerspezifische oder strikt konsistente Daten nie ohne bewusstes Design. ## Messen Sie die P95-Latenz, bevor Sie einen Cache einführen Durchschnittswerte verbergen genau die Anfragen, über die sich Nutzer beschweren. Erfassen Sie die P95- und P99-Latenz pro Endpoint zusammen mit dem Anfragevolumen, damit Sie sehen, welche Routen zugleich langsam und stark genutzt sind. Finden Sie dann heraus, wo die Zeit verloren geht. Ein Trace oder eine einfache Zeitaufschlüsselung pro Anfrage zeigt meist, ob eine langsame Abfrage, wiederholte Abfragen, ein externer API-Aufruf oder die Serialisierung die Kosten verursacht. Wer eine Antwort cacht, deren eigentliches Problem ein fehlender Index ist, versteckt dieses Problem nur bis zum nächsten Cache-Miss. - Erfassen Sie P50, P95 und P99 pro Endpoint, nicht nur eine globale Zahl - Sortieren Sie Endpoints nach Anfragevolumen mal Latenz, um zu sehen, wo sich Caching am meisten lohnt - Prüfen Sie das Verhältnis von Lese- zu Schreibzugriffen: Daten, die viel öfter gelesen als geändert werden, sind die besten Kandidaten - Beheben Sie fehlende Indizes und N+1-Abfragen, bevor Sie sie mit einem Cache umgehen ## Nutzen Sie Cache-Aside als Standardmuster Bei Cache-Aside fragt die Anwendung zuerst Redis ab. Bei einem Treffer gibt sie den gecachten Wert zurück. Bei einem Miss liest sie aus der Datenbank, schreibt das Ergebnis mit einer TTL in Redis und gibt es zurück. Bei diesem Muster bleibt die Datenbank die maßgebliche Quelle, und Ausfälle bleiben beherrschbar. Ist Redis langsam oder nicht erreichbar, weicht die Anwendung auf die Datenbank aus, mit kurzem Timeout und einem Circuit Breaker, damit ein angeschlagener Cache nicht jede Anfrage bremst. Entwerfen Sie Schlüssel bewusst. Nehmen Sie den Ressourcentyp, die Kennung, die API-Version und jeden Parameter auf, der die Antwort verändert, etwa Sprache oder Seite. Erst ein vorhersehbares Schlüsselschema macht später eine gezielte Invalidierung möglich. ## Legen Sie TTLs nach der zulässigen Veralterung fest und invalidieren Sie bei Änderungen Eine TTL ist eine geschäftliche Entscheidung in Form einer Zahl. Fragen Sie, wie alt die Daten sein dürfen, bevor ein Nutzer oder ein nachgelagertes System Schaden nimmt, und leiten Sie die TTL aus dieser Antwort ab. Ein Live-Spielstand und ein archivierter Artikel vertragen sehr unterschiedlich viel Veralterung. Wer sich nur auf den Ablauf verlässt, liefert veraltete Daten aus, bis die TTL abläuft. Bei Daten, die Ihre eigene Anwendung ändert, löschen oder überschreiben Sie den Schlüssel, nachdem der Schreibvorgang committet ist, idealerweise über ein Ereignis, das nach der Transaktion ausgelöst wird. So enthält der Cache nie Daten, die die Datenbank zurückgerollt hat. Versehen Sie die TTLs mit einem kleinen zufälligen Jitter, damit gleichzeitig geschriebene Schlüssel nicht alle im selben Moment ablaufen. - Kurze TTL von wenigen Sekunden für schnell wechselnde Daten, bei denen leichte Veralterung akzeptabel ist - Längere TTL plus Invalidierung beim Schreiben für Daten, die Sie selbst kontrollieren und die sich selten ändern - Versionierte Schlüssel: Das Hochzählen einer Versionsnummer invalidiert eine ganze Gruppe von Schlüsseln auf einmal ## Schützen Sie die Datenbank vor Cache Stampedes Ein Stampede entsteht, wenn ein beliebter Schlüssel abläuft, viele gleichzeitige Anfragen ihn verfehlen und alle dieselbe teure Abfrage an die Datenbank schicken. Bei einer API mit hohem Traffic kann das die Datenbank genau dann überlasten, wenn der Traffic seinen Höhepunkt erreicht. Kombinieren Sie für Ihre meistgenutzten Schlüssel zwei oder mehr dieser Schutzmaßnahmen. - Request Coalescing: Eine einzige Anfrage baut den Schlüssel unter einer kurzen Redis-Sperre neu auf, gesetzt mit NX und einer Ablaufzeit, während die anderen kurz warten oder den vorherigen Wert ausliefern - Stale-while-revalidate: Speichern Sie im Wert eine weiche Ablaufzeit, liefern Sie die veraltete Kopie darüber hinaus weiter aus und aktualisieren Sie im Hintergrund - Frühe probabilistische Aktualisierung: Bauen Sie einen stark genutzten Schlüssel gelegentlich vor seinem Ablauf neu auf, mit steigender Wahrscheinlichkeit, je näher der Ablauf rückt - Vorwärmen: Befüllen Sie bekannte, stark genutzte Schlüssel vor einer geplanten Traffic-Spitze, etwa vor einem großen Live-Event ## Nutzen Sie Elasticsearch für Suche und Listen, nicht als allgemeinen Cache Redis eignet sich am besten für Key-Value-Zugriffe: ein einzelnes Objekt, ein berechnetes Fragment, ein Zähler für Rate Limiting. Elasticsearch erfüllt eine andere Aufgabe: Volltextsuche, facettierte Filter und sortierte Listen, die in einer relationalen Datenbank teuer zu berechnen sind. Behandeln Sie den Elasticsearch-Index als Lesemodell, das aus der primären Datenbank gespeist wird, über Änderungsereignisse oder eine geplante Synchronisation, und akzeptieren Sie, dass er nur letztendlich konsistent ist. Die Datenbank bleibt maßgeblich für Schreibvorgänge und für alles, was exakt sein muss. Auf der Sportmedienplattform von NorthStar Network, die 50M+ Nutzer im Monat bedient, haben unsere Entwickler die Architektur kritischer APIs überarbeitet und das Caching über Redis und Elasticsearch neu gestaltet, was die P95-Antwortzeiten senkte. ## Was Sie nicht cachen sollten Der teuerste Caching-Fehler ist, die Daten eines Nutzers an einen anderen auszuliefern. Prüfen Sie bei jedem gecachten Endpoint, ob die Identität im Schlüssel steckt, und testen Sie ihn vor dem Release mit zwei verschiedenen Konten. - Antworten, die von der Identität oder den Berechtigungen des Aufrufers abhängen, es sei denn, der Schlüssel enthält Nutzer oder Rolle - Daten, die strikt konsistent sein müssen, etwa Kontostände, der Lagerbestand beim Checkout oder alles, was in Autorisierungsentscheidungen einfließt - Schreibende Endpoints, Einmal-Tokens und alles mit Seiteneffekten - Endpoints mit wenig Traffic, bei denen ein Cache für wenig Nutzen Komplexität und eine neue Fehlerquelle hinzufügt - Sehr große Payloads, die viele kleinere, häufiger genutzte Schlüssel verdrängen ## Machen Sie den Cache beobachtbar, sonst können Sie ihm nicht vertrauen Verfolgen Sie die Trefferquote pro Schlüsselpräfix, Speichernutzung und Evictions von Redis, die Latenz der Redis-Befehle und die Datenbanklast, zusammen mit dem P95 der API auf demselben Dashboard. Wenn sich der P95 bewegt, sollten Sie innerhalb von Minuten erkennen, ob der Cache, die Datenbank oder ein vorgelagerter Dienst die Ursache ist. Richten Sie Alarme ein für einen plötzlichen Einbruch der Trefferquote, der oft bedeutet, dass ein Deployment ein Schlüsselformat geändert hat, und für steigende Evictions, die zeigen, dass der Cache für die aktiv genutzten Daten zu klein ist. Wir übernehmen API-Performance-Arbeit als klar abgegrenztes Paket: messen, die Caching-Schicht neu gestalten und Dashboards und Runbooks an das Team übergeben, das sie betreibt. ## Das Wichtigste in Kürze - Messen Sie P95 pro Endpoint und beheben Sie Abfrageprobleme, bevor Sie einen Cache hinzufügen. - Cache-Aside in Redis ist der sicherste Standard, weil die Datenbank die maßgebliche Quelle bleibt. - Leiten Sie TTLs davon ab, wie veraltet die Daten sein dürfen, und invalidieren Sie beim Schreiben, wo Sie die Daten kontrollieren. - Schützen Sie stark genutzte Schlüssel mit Sperren, Stale-while-revalidate oder Vorwärmen vor Stampedes. - Nutzen Sie Elasticsearch als letztendlich konsistentes Lesemodell für Suche und Listen, nicht als allgemeinen Cache. ## FAQ ### Redis oder Elasticsearch: Womit sollte man API-Antworten cachen? Nutzen Sie Redis für das Key-Value-Caching von Objekten, berechneten Fragmenten und Zählern, weil Zugriffe per Schlüssel schnell und einfach zu invalidieren sind. Nutzen Sie Elasticsearch, wenn Suche, Filtern oder Sortieren über viele Datensätze der teure Teil ist, und behandeln Sie seinen Index als Lesemodell statt als Cache. ### Welche TTL ist für API-Antworten sinnvoll? Einen allgemeingültigen Wert gibt es nicht. Legen Sie jede TTL danach fest, wie veraltet die Daten sein dürfen, ohne einem Nutzer zu schaden, nehmen Sie wenige Sekunden für schnell wechselnde Daten und kombinieren Sie längere TTLs mit Invalidierung beim Schreiben. Fügen Sie zufälligen Jitter hinzu, damit zusammengehörige Schlüssel nicht gemeinsam ablaufen. ### Wie verhindert man einen Cache Stampede in Redis? Lassen Sie nur eine Anfrage einen abgelaufenen Schlüssel neu aufbauen, indem sie mit SET und der Option NX eine kurze Sperre setzt, und lassen Sie die anderen Anfragen kurz warten oder den vorherigen Wert ausliefern. Stale-while-revalidate und die frühe Aktualisierung stark genutzter Schlüssel verringern von vornherein die Zahl harter Abläufe. ## Passende Leistungen - [Individualsoftware](https://sdk.enterprises/de/services/product-engineering)