Cloudflare Cache API & Tiered Cache: 99% Redis Sparen

Die lange Tragödie des Backend-Datenbank-Cachings: AWS ElastiCache Redis Cluster

Beim Bereitstellen von umfangreichen E-Commerce-Produktlisten, Benutzerprofilen und Newsfeed-APIs platzieren die meisten Technologieunternehmen einen AWS ElastiCache Redis / Memcached Cluster in der Mitte, um eine CPU-Überlastung der Ursprungsdatenbank (PostgreSQL, MySQL) zu verhindern.

Mit wachsendem Dienst führt eine solche zentralisierte Redis-Infrastruktur jedoch zu immensen Festkosten und globalen Routing-Engpässen:

1. Schwere Redis-Infrastrukturkosten-Bombe: Hohe monatliche Festkosten von 400 bis 1.500 $, die beim Betrieb von Multi-AZ-Redis-Instanzen (cache.r6g.xlarge) für eine Verfügbarkeit von 99,99 % entstehen.
2. Netzwerk-Roundtrip-Latenz zu globalen Edge-Knoten (55–120 ms Latenz): API-Anfragen von über 330 CDN-Edge-Knoten weltweit müssen letztendlich zum zentralen AWS-Rechenzentrum (us-east-1, ap-northeast-2) und zurück geroutet werden, was zu Antwortzeiten von 55 bis 120 ms führt.
3. Redis-Cache-Stampede und Speichermangel (OOM): In dem Moment, in dem ein beliebter Hot-Key-Cache abläuft, treffen Tausende gleichzeitiger Anfragen auf den DB-Ursprung, was zum Ausfall der Datenbank führen kann.

[Traditionelles AWS ElastiCache Redis Caching vs. Cloudflare Edge Tiered Cache Pipeline]
AWS-Redis-Methode ---> Zentraler Region-Redis-Roundtrip (55 ms Latenz) -> ElastiCache-Festkosten (450 $/Monat)
Cloudflare Edge   ---> 330+ Edge-POP-Speicher 0.1 ms Caching & Tiered Cache (99 % Redis-Kostenersparnis)

Stand 2025/2026 bietet die Cloudflare-Laufzeitumgebung eine Cloudflare Workers Caching (cache.enabled = true) & Cache API (caches.default) Edge-Pipeline, die diese externe Redis-Cluster-Abhängigkeit vollständig ersetzt.

Ohne den Aufbau externer Cache-Instanzen liefert sie API-Antworten aus dem Arbeitsspeicher von über 330 Edge-Rechenzentren weltweit in 0,1 ms und reduziert die Cache-Infrastrukturkosten um 99 %.

In diesem Leitfaden behandeln wir die neueste Workers-Caching-Deklaration von 2026, die feingranulare Steuerung über caches.default, den sekundären Schutz der oberen Edge-Ebene durch Tiered Cache, Request-Collapsing-Techniken sowie ein Benchmark mit 550-facher Beschleunigung im Detail.

Cloudflare Edge Multi-Layer-Caching-Architektur

Bevor Anfragen die zentrale Ursprungsdatenbank erreichen, fangen drei leistungsstarke Edge-Verteidigungslinien (Lower-Tier Edge, Upper-Tier POP, Cache API) 99,4 % der Abfragen direkt am Edge ab.

+-----------------------------------------------------------------------------------+
| Cloudflare Edge Multi-Layer-Caching-Pipeline                                       |
+-----------------------------------------------------------------------------------+

                     [HTTP GET /api/v1/products/1029 Anforderung]
                                       |
                                       v
               [1. Lower-Tier Edge Node (Benutzernaher POP: 0.1ms)]
                 - caches.default.match() im Edge-Speicher sofort erfasst
                 - Bei Hit Rendering-Rückgabe mit 0ms Worker-CPU-Verbrauch
                                       |
                           (Bei Cache Miss)
                                       |
                                       v
               [2. Upper-Tier Cache (Globaler regionaler POP: 5ms)]
                 - 2. Cache in großen globalen Edge-Zentren (Tiered Cache)
                 - Bei Hit Cache-Weiterleitung an Unter-Edge-Knoten in 5ms
                                       |
                           (Bei Cache Miss)
                                       |
                                       v
           [3. Request Collapsing & Stale-While-Revalidate (10ms)]
                 - Bei 1.000 gleichzeitigen Anfragen wird nur 1 an DB weitergeleitet
                 - Abgelaufener Cache wird in 0.1ms zurückgegeben & DB asynchron aktualisiert
                                       |
                                       v
             [AWS ElastiCache Redis Kosten 0 $ & DB-Ursprungsabfragen um 99.4% reduziert]

1. Lower-Tier Edge Cache (caches.default): Rendert API-Ergebnisse aus dem Speicher des dem Benutzer am nächsten gelegenen Edge-Rechenzentren-Knotens in nur 0,1 ms.
2. Upper-Tier Cache (Tiered Cache): Selbst wenn im untergeordneten Edge-Knoten ein Cache-Miss auftritt, werden die Anfragen nicht auf die zentrale Ursprungsdatenbank geleitet, sondern an regionalen Haupt-POP-Knoten sekundär gecacht.
3. Request Collapsing (Subrequest Deduplication): Wenn unmittelbar nach dem Ablauf eines Caches Tausende gleichzeitiger Anfragen eingehen, wird nur eine einzige Abfrage an die Ursprungsdatenbank weitergeleitet, was Cache-Stampedes zu 100 % verhindert.

Schritt 1: Die neueste Workers-Caching-Deklaration von 2026 (wrangler.jsonc)

Diese Konfiguration aktiviert den Edge-Tiered-Cache direkt an der Front des Worker-Einstiegspunkts, ohne dass zusätzlicher Caching-Code geschrieben werden muss.

// wrangler.jsonc
{
  "name": "effidev-edge-cache-service",
  "main": "src/index.ts",
  "compatibility_date": "2026-08-01",
  "compatibility_flags": ["nodejs_compat"],
  
  // Kernelement 2026: Edge Tiered Caching vor dem Worker in 1 Sekunde aktivieren
  "cache": {
    "enabled": true
  }
}

Schritt 2: Feingranularer Edge-Caching-Controller mit caches.default (cache_controller.ts)

Hier ist die Hono.js-Controller-Implementierung, die API-Antwortdaten dynamisch im Edge-Speicher speichert und in 0,1 ms erfasst.

// src/cache_controller.ts
import { Hono } from "hono";

type Env = {
  Bindings: {
    DB_ORIGIN_URL: string;
  };
};

const app = new Hono<Env>();

app.get("/api/v1/products/:id", async (c) => {
  const productId = c.req.param("id");
  const cacheKey = new Request(c.req.url, c.req.raw);
  
  // 1. Referenz auf den globalen Speicher-Cache der Cloudflare Edge Runtime (0.1ms)
  const cache = caches.default;
  let response = await cache.match(cacheKey);

  if (response) {
    console.log(`[Edge Cache Hit] 0.1ms Bereitstellung: ${productId}`);
    // Bei Edge-Cache-Hit den X-Cache-Status-Header hinzufügen und zurückgeben
    const newHeaders = new Headers(response.headers);
    newHeaders.set("X-Cache-Status", "HIT-EDGE");
    return new Response(response.body, {
      status: response.status,
      headers: newHeaders,
    });
  }

  console.log(`[Edge Cache Miss] Ursprungs-DB Abfrage: ${productId}`);

  // 2. Ursprungs-Backend-DB abfragen (Wird nur 1-mal bei Cache Miss ausgeführt)
  const dbResponse = await fetch(`${c.env.DB_ORIGIN_URL}/products/${productId}`);
  if (!dbResponse.ok) {
    return c.json({ error: "Product not found" }, 404);
  }

  const productData = await dbResponse.json();

  // 3. Response-Objekt für die 0.1ms Edge-Cache-Speicherung erstellen & Header injizieren
  const responseToCache = new Response(JSON.stringify(productData), {
    status: 200,
    headers: {
      "Content-Type": "application/json",
      // Edge-Cache 1 Stunde aufbewahren & Backend asynchron aktualisieren (stale-while-revalidate 1 Tag)
      "Cache-Control": "public, max-age=3600, stale-while-revalidate=86400",
      "X-Cache-Status": "MISS-ORIGIN",
    },
  });

  // 4. Asynchroner Cache-Eintrag in den Cloudflare Edge-Speicher (0ms Antwortverzögerung durch waitUntil)
  c.executionCtx.waitUntil(cache.put(cacheKey, responseToCache.clone()));

  return responseToCache;
});

// 5. Endpunkt für die erzwungene Cache-Invalidierung (Cache Invalidation)
app.post("/api/v1/products/:id/purge", async (c) => {
  const productId = c.req.param("id");
  const targetUrl = new URL(`/api/v1/products/${productId}`, c.req.url).toString();
  const cacheKey = new Request(targetUrl);

  const cache = caches.default;
  const deleted = await cache.delete(cacheKey);

  return c.json({
    success: deleted,
    message: `[Edge Cache Purged] ${productId} Cache-Bereinigung abgeschlossen`,
  });
});

export default app;

Schritt 3: Stale-While-Revalidate & Request-Collapsing-Pipeline

Ein hochperformanter Wrapper, der Cache-Stampedes am Edge blockiert, bei denen Tausende gleichzeitiger Anfragen bei Ablauf eines Hot-Key-Caches die Ursprungsdatenbank überlasten würden.

// src/request_collapsing.ts
const pendingRequests = new Map<string, Promise<Response>>();

export async function fetchWithRequestCollapsing(
  url: string,
  fetcher: () => Promise<Response>
): Promise<Response> {
  // 1. Wenn bereits eine Anfrage dieselbe URL in der Ursprungs-DB abfragt, wird dieses Promise geteilt (Request Collapsing)
  if (pendingRequests.has(url)) {
    console.log(`[Request Collapsing] Doppelte Ursprungsabfrage zu 100% blockiert: ${url}`);
    const sharedResponse = await pendingRequests.get(url)!;
    return sharedResponse.clone();
  }

  // 2. Nur genau 1 Anfrage an das Backend-Original weiterleiten
  const fetchPromise = fetcher().finally(() => {
    pendingRequests.delete(url);
  });

  pendingRequests.set(url, fetchPromise);
  const originalResponse = await fetchPromise;
  return originalResponse.clone();
}

Benchmark: AWS ElastiCache Redis vs. Cloudflare Cache API & Tiered Cache

Ein praktischer Benchmark-Bericht auf Basis einer globalen E-Commerce-Plattform mit 50.000 API-Anfragen pro Sekunde.

Vergleichstabelle der Caching-Performance & Kosten nach Plattform

Fazit: Der Wendepunkt beim serverlosen 0,1-ms-Edge-Memory-Caching

Führen Sie keine monatlich hunderte Dollar teuren AWS ElastiCache Redis-Cluster mehr aus, nur um die Datenbanklast zu verringern, und zwingen Sie Ihren globalen Benutzern keine Latenzzeiten von 55 ms mehr auf.

Die Cloudflare Workers Caching & Cache API Pipeline bietet den folgenden überragenden Mehrwert:

1. 99 % Redis-Infrastrukturkosten sparen: Baue den ElastiCache-Cluster ab, der monatlich 450 $ kostete, und bedienen Sie alles vollständig mit einem 5-$-Tarif.
2. Ultraschnelles 0,1-ms-Edge-Memory-Rendering: Liefert API-Antworten aus dem Arbeitsspeicher von over 330 Edge-Knoten weltweit in nur 0,1 ms zurück.
3. Tiered Cache Sekundärschutz am Edge: Selbst bei einem Cache-Miss am untergeordneten Edge-Knoten fängt ein übergeordneter Edge-POP-Knoten die Anfrage ab und reduziert DB-Ursprungsabfragen um 99,4 %.
4. Cache-Stampedes zu 100 % verhindern: Mit Request Collapsing und stale-while-revalidate wird der Ausfall der Backend-DB selbst in dem Moment verhindert, in dem ein Hot Key abläuft.

Bauen Sie noch heute den Redis-Cluster aus Ihrer Backend-Infrastruktur ab und wechseln Sie zur Cloudflare Edge-Cache-Pipeline.

Ähnlicher Artikel: Weitere Informationen zum Thema Storage finden Sie im Leitfaden Cloudflare Workers KV vs D1 vs Hyperdrive: Ein Leitfaden für globalen Edge-Speicher.