Was ist API-Caching?

Was ist API-Caching?

API-Caching ist die Praxis, Antworten von einer API zu speichern, sodass nachfolgende identische Anfragen aus dem Cache bedient werden können, statt die zugrundeliegende Arbeit erneut auszuführen. Die gecachte Antwort ist normalerweise frisch genug — für viele Endpoints ändern sich Daten weit seltener als sie gelesen werden — und das Bedienen aus dem Cache ist dramatisch schneller als das Neuberechnen aus Datenbanken oder Downstream-Services. Caching ist eine der hebelstärksten Optimierungen im API-Engineering: ein gut platzierter Cache kann p95-Latenz um 10-100x kürzen und Backend-Last um 90%+ reduzieren.

Cache-Standorte stapeln sich: Browser → CDN → API-Gateway → Application-Memory → verteilter Cache (Redis/Memcached) → Database-Query-Cache. Jede Schicht schneidet einen Bruchteil der Anfragen, mit progressiv höheren Hit-Raten und niedrigeren Kosten, je näher du am Nutzer bist. Effektive API-Caching-Strategie wählt die richtige Schicht (oder Schichten) für jeden Endpoint basierend auf Zugriffsmustern und Frische-Anforderungen.

Die fünf Haupt-API-Caching-Schichten

1. Client- / Browser-Cache

Der Browser speichert Antworten basierend auf HTTP-Cache-Control-Headern. Null Round-Trip, wenn gecacht. Am besten für Content, der sicher pro Nutzer lokal gecacht werden kann (statische Assets, öffentliche Referenzdaten). Gesteuert durch Cache-Control: max-age=3600 und ETags.

2. CDN-Edge-Cache (Cloudflare, CloudFront, Fastly)

Gecacht an Edge-POPs nahe Nutzern. ~10-50ms Antwortzeit global. Am besten für Content, der für viele Nutzer gecacht wird (öffentliche APIs, anonymisierte Daten, Marketing-Endpoints). Gesteuert durch Cache-Control-Header + CDN-spezifische Cache-Regeln.

3. API-Gateway-Cache (AWS API Gateway, Kong, Apigee)

Zentralisierter Cache vor deinen APIs. Reduziert Backend-Hits ohne Browser-/CDN-Kooperation. Nützlich für gemeinsame Logik vor dem Routing zu Services.

4. Application-Level-Cache (in-Process oder verteilt)

Am flexibelsten: cache alles im Speicher (in-Process) oder in Redis/Memcached (über Instanzen geteilt). Am besten für berechnete Antworten, die nicht ins CDN zu pushen lohnt. Häufiges Pattern: cache die teure Read-Query, nicht die volle HTTP-Antwort.

5. Database-Query-Cache

Viele Datenbanken cachen Query-Pläne und häufige Ergebnisse intern. Weniger Kontrolle, aber oft automatisch. PostgreSQLs shared_buffers, MySQLs Query-Cache (post-8.0 deprecated), Redis als Datenbank-Cache-Schicht.

HTTP-Caching-Header (der Standard)

RFC 9111 definiert die Cache-Semantik, der jedes CDN, jeder Browser und Reverse-Proxy folgt:

• Cache-Control: public, max-age=3600 — cachebar von jedem für 1 Stunde.
• Cache-Control: private, max-age=300 — nur der Browser des Nutzers kann cachen (nicht CDN), 5 Minuten.
• Cache-Control: no-store — niemals cachen (sensible Daten).
• Cache-Control: no-cache — muss revalidieren vor Wiederverwendung (gecacht, aber bedingt).
• Cache-Control: stale-while-revalidate=60 — serve stale bis zu 60s extra, während frisch im Hintergrund gefetched wird. Großer UX-Gewinn.
• ETag: "abc123" — Content-Fingerprint. Client sendet If-None-Match: "abc123"; Server antwortet 304, wenn unverändert.
• Vary: Accept-Encoding, Authorization — Cache-Key beinhaltet diese Header (anderer Content pro Encoding/Nutzer).

Häufige Caching-Strategien

• Cache-Aside (Lazy Loading). App prüft Cache; bei Miss fetcht aus der Quelle und füllt den Cache. Einfach, häufig.
• Read-Through. Cache-Schicht fetcht transparent bei Miss. Weniger App-Code; erfordert, dass der Cache die Quelle kennt.
• Write-Through. Writes gehen zu Cache + Quelle gleichzeitig. Cache ist immer konsistent, aber langsamere Writes.
• Write-Back. Writes gehen zu Cache; Quelle async aktualisiert. Schnelle Writes, aber Verlustrisiko bei Cache-Ausfall.
• Refresh-Ahead. Cache aktualisiert proaktiv, bevor TTL abläuft. Glatte Latenz, erfordert gute Vorhersage.

Cache-Invalidierung: das schwere Problem

Phil Karltons Zitat ist berühmt: "Es gibt nur zwei schwere Dinge in der Informatik: Cache-Invalidierung und Dinge benennen." Strategien:

• TTL-basiert. Setze Cache-Control max-age. Einfach. Tradeoff: veraltete Daten bis zu TTL nach Änderung.
• Manuelles Purge. Rufe CDN/Cache-API auf, um spezifische Keys zu invalidieren, wenn Daten sich ändern. Präzise; erfordert, dass Writes wissen, welche Keys.
• Versionierte URLs. Hänge Version an (/api/products?v=42), sodass Änderungen frische URLs bekommen. Alte Cache-Einträge sterben natürlich.
• Event-getriebene Invalidierung. Pub/Sub broadcasted "Produkt 42 hat sich geändert"; Cache-Schichten lauschen und purgen. Genauester; komplexester.
• Surrogate Keys (Cache-Tags). Tagge Antworten mit logischen Keys ("user:42", "products") und purge nach Tag. Fastly, Cloudflare Enterprise unterstützen das.

Häufige API-Caching-Fehler

• Authentifizierte Antworten öffentlich cachen. Daten eines eingeloggten Nutzers landen im geteilten Cache; ein anderer Nutzer sieht sie. Setze immer Cache-Control: private für personalisierte Antworten.
• Vary-Header vergessen. Cache gibt gzipped Antwort an Client zurück, der Identity-Encoding anfragt. Inkludiere immer Vary: Accept-Encoding.
• TTL zu lang. Stunden veralteter Daten nach jedem Update. Stimme TTL auf deine tatsächliche Änderungsfrequenz ab.
• TTL zu kurz. Cache-Hit-Rate <50% bedeutet, du cachst nicht wirklich. Ziele auf 90%+ Hit-Rate auf gecachten Endpoints.
• Cache-Stampede. Wenn TTL abläuft, missen 1.000 konkurrente Anfragen alle und treffen die Datenbank. Mitigiere mit Locks ("nur ein Fetch bei Miss"), Refresh-Ahead oder Stale-While-Revalidate.
• Fehler cachen. Ein 500-Fehler wird für 5 Minuten gecacht; Nutzer sehen weiterhin die kaputte Antwort. Setze immer Cache-Control: no-store auf Fehlerantworten.
• Keine Observability. Ohne Metriken über Hit-Rate, Miss-Rate und Origin-Last kannst du nicht tunen. Tracke diese pro Endpoint.

FAQ: API-Caching

Wie weiß ich, was zu cachen?

Profile deine API: welche Endpoints sind am langsamsten? Am häufigsten requested? Haben stabile Daten? Das sind Caching-Kandidaten. Tools wie Datadog APM zeigen Endpoint-Latenz und Request-Rate Seite an Seite.

Was ist eine gute Cache-Hit-Rate?

Für gut gecachte Endpoints ziele auf 90%+ Hit-Rate am CDN. Niedriger bedeutet, TTLs sind zu kurz oder du cachst Dinge, die nicht gecacht werden sollten (Pro-Nutzer-Daten). Unter 50% bedeutet, Caching hilft kaum.

Kann ich POST-Requests cachen?

Generell nein — HTTP-Semantik behandelt POSTs als zustandsverändernd. Manche APIs cachen idempotente POSTs (z.B. Search) auf Application-Schicht mit expliziten Cache-Keys, aber das CDN tut das nicht für dich.

Wie interagiert API-Caching mit Rate-Limiting?

Cache-Hits umgehen typischerweise Rate-Limits (sie erreichen den rate-limited Endpoint nicht). Das schützt Backends, bedeutet aber, missbräuchliche Nutzer können einen gecachten Endpoint frei hämmern. Für sensible Endpoints rate-limite am CDN-Edge.

Was ist mit GraphQL-Caching?

Schwieriger als REST. Die Query ist im POST-Body, also schlägt URL-basiertes Caching fehl. Lösungen: Persisted Queries (verwandle komplexe Queries in IDs, cachebar als GET), Apollos Automatic Persisted Queries, Query-Level-Cache-Hints.

Wie teste ich API-Caching?

Funktional: sende identische Anfragen, verifiziere, dass die zweite schneller ist (X-Cache: HIT-Header, niedrigere Latenz). Unter Last: Lasttest mit Cache aktiviert vs. deaktiviert, um Backend-Schutz zu messen.

Was ist der Unterschied zwischen Caching und CDN?

Ein CDN ist ein Liefer-Netzwerk mit Caches an Edge-POPs. "Caching" ist die breitere Praxis, Antworten auf jeder Schicht zu speichern. CDN-Caching ist ein spezifischer Fall.

Wie LoadFocus zu API-Caching-Strategie steht

Der Wert von API-Caching zeigt sich nur unter realistisch konkurrentem Traffic. LoadFocus-API-Lasttest misst Backend-Hit-Rate (Cache-Miss = Traffic, der dein Origin trifft) unter realistischer Konkurrenz und bringt Cache-Stampedes und ineffektive TTLs ans Licht. API-Monitoring trackt Cache-Hit-Rate über Zeit, sodass du Regressionen fängst, wenn ein Deploy versehentlich den Cache umgeht.