Cache und Edge-Schicht: CDN, Edge-Cache, ETag, SWR, Edge Functions (Vercel) und ihre Limits

1. Warum überhaupt über Cache und Edge in der ChatGPT App nachdenken

In einer klassischen Webanwendung sorgt man sich ebenfalls um Geschwindigkeit, aber dort sieht der/die Nutzer:in immerhin einen Spinner. In der ChatGPT App ist die Situation spannender: Der/die Nutzer:in spricht mit dem Modell, das entscheidet bisweilen, eure App aufzurufen. Das Widget sollte aufpoppen und ziemlich schnell etwas Nützliches zeigen.

Die Praxis ist ziemlich eindeutig: Latenz = Geld. Je länger ihr antwortet, desto größer die Chance, dass der/die Nutzer:in abspringt, und zusätzliche Aufrufe von LLM/Backend sind direkte Kosten für Modelle und Infrastruktur. Caching reduziert beides.

Plus die Spezifika von ChatGPT Apps:

• Anfragen von ChatGPT an eure App laufen durchs Netzwerk und diverse Schichten. Jede Millisekunde auf jedem Schritt summiert sich.
• MCP-/HTTP-Endpunkte haben echte Timeouts (auch bei Vercel-Serverless- und Edge-Funktionen). Wenn ihr es nicht rechtzeitig schafft, sieht ChatGPT einen Fehler und kann sogar anfangen, eine Antwort zu „halluzinieren“.
• Viele Daten in GiftGenius ändern sich nicht jede Sekunde: Struktur des Geschenk-Katalogs, Sammlungen „Top-Ideen“ für verschiedene Segmente, Feature-Settings. Es ist unsinnig, jedes Mal erneut die Datenbank oder ein externes API zu schlagen.

Und hier kommen ins Spiel:

• CDN und Edge-Cache, um statische Assets und cachebares JSON schnell auszuliefern.
• HTTP-Cache mit Cache-Control/ETag/SWR, damit Wiederholungsanfragen schneller und günstiger werden.
• Vercel-Edge-Funktionen, um leichte Logik so nah wie möglich an ChatGPT und den/die Nutzer:in zu bringen – ohne sie zu einem „Mini-Backend“ zu machen.

2. Anatomie der Latenzen in GiftGenius und Caching-Punkte

Zuerst ist es hilfreich, ehrlich aufzuzeichnen, wo die Latenz überhaupt entsteht.

sequenceDiagram
    participant User as Benutzer
    participant ChatGPT as ChatGPT
    participant App as ChatGPT App (Apps SDK)
    participant GW as MCP Gateway / Edge
    participant GiftAPI as Gift REST API / Geschenk-Mikroservice
    participant DB as Katalog/Datenbank

    User->>ChatGPT: "Finde ein Geschenk für meinen Bruder"
    ChatGPT->>App: Toolaufruf + Widget-Rendering
    App->>GW: HTTP / MCP Anfrage (Kategorien, Sammlungen)
    GW->>GiftAPI: HTTP (REST)
    GiftAPI->>DB: Anfrage Katalog/Empfehlungen
    DB-->>GiftAPI: Antwort
    GiftAPI-->>GW: Antwort (JSON)
    GW-->>App: Antwort (JSON)
    App-->>ChatGPT: Widget mit Ergebnissen
    ChatGPT-->>User: Nachricht + UI

Wo kann man hier „abkürzen“?

1. Zwischen ChatGPT und eurem Perimeter — CDN/Edge-Cache (Vercel CDN/Edge Network), der unveränderliche Widget-Assets und cachebares JSON ausliefern kann, ohne euren Origin-Server zu berühren.
2. Zwischen Gateway und internen REST-/HTTP-Services (Gift REST API, Commerce REST API etc.) sowie der Datenbank — Anwendungscache (Redis/im Speicher/DB-Cache), um gleiche Anfragen (z. B. „Liste der Geschenk-Kategorien“) nicht zehnmal durchzureichen.

In dieser Vorlesung fokussieren wir uns auf die HTTP-/Edge-Schicht, weil sie näher an ChatGPT und Vercel liegt.

3. Cache-Arten in unserer Architektur

Wenn unsere Architektur ein „Schichtkuchen“ ist, gibt es darin mehrere Caches.

Jetzt konzentrieren wir uns auf die ersten beiden: HTTP-Cache + CDN/Edge.

4. HTTP-Cache: Cache-Control, max-age und s-maxage

Der HTTP-Cache wird in erster Linie über den Header Cache-Control gesteuert. Er bestimmt, ob und wie lange Browser/ChatGPT-Client und/oder CDN eure Antwort cachen dürfen.

Schlüsselbegriffe:

• max-age — wie viele Sekunden der Browser die Antwort cachen darf.
• s-maxage — wie viele Sekunden ein Shared Cache (CDN/Proxy) cachen darf.
• public — die Antwort darf in einem Shared Cache gespeichert werden.
• private — die Antwort ist nur für einen konkreten Client; das CDN cached sie nicht.

In GiftGenius zum Beispiel:

• JS/CSS/Fonts des Widgets — versionierte Dateien (mit Hash im Namen), die man problemlos mit Cache-Control: max-age=31536000, immutable ausliefern kann.
• JSON mit der Liste der Geschenk-Kategorien — identisch für alle Nutzer:innen, hier ist sinnvoll: public, s-maxage=60 (oder mehr).

Ein einfaches Next.js-Route-Handler-Beispiel für GET /api/gifts/categories, das im CDN für 60 Sekunden gecached wird:

// app/api/gifts/categories/route.ts
import { NextResponse } from "next/server";

export const runtime = "nodejs"; // gewöhnliche Serverless-Funktion

export async function GET() {
  // hier könnten wir DB/externe API aufrufen
  const categories = [
    { id: "for_brother", title: "Geschenke für den Bruder" },
    { id: "for_mom", title: "Geschenke für die Mutter" },
  ];

  return NextResponse.json(categories, {
    headers: {
      // wir erlauben dem CDN, 60 Sekunden zu cachen
      "Cache-Control": "public, s-maxage=60",
    },
  });
}

Das Vercel-CDN hält die Antwort 60 Sekunden vor, und alle ChatGPT-Anfragen nach diesem JSON erreichen eure Funktion während dieses Fensters gar nicht. Das ist sofort und günstig.

5. ETag: Fingerabdruck des Inhalts und 304 Not Modified

ETag ist ein bedingter „Fingerabdruck“ einer Ressource, üblicherweise ein Hash des Inhalts. Ablauf:

1. Der Server liefert eine Antwort mit dem Header ETag: "v1-abc123".
2. Beim nächsten Mal sendet der Client den Header If-None-Match: "v1-abc123".
3. Wenn der Server meint, dass sich der Inhalt nicht geändert hat, antwortet er mit 304 Not Modified ohne Body.

Wichtig: ETag spart Traffic, reduziert aber nicht zwingend die Latenz, denn ein Roundtrip zum Server ist trotzdem nötig. Im Kontext von ChatGPT Apps ist das nützlich für schwere JSON-Antworten, aber erwartet keine Wunder bei der Geschwindigkeit allein durch ETag — dafür sind SWR und Edge-Cache besser geeignet.

Beispiel für ein einfaches ETag im Next.js-Handler (ohne Kryptohashes, um es simpel zu halten):

// app/api/gifts/config/route.ts
import { NextRequest, NextResponse } from "next/server";

const CONFIG = { version: 1, showExperimentalIdeas: true };
const ETAG = `"v${CONFIG.version}"`;

export async function GET(req: NextRequest) {
  const ifNoneMatch = req.headers.get("if-none-match");
  if (ifNoneMatch === ETAG) {
    // Inhalt unverändert — wir geben 304 zurück
    return new NextResponse(null, { status: 304, headers: { ETag: ETAG } });
  }

  return NextResponse.json(CONFIG, {
    headers: {
      ETag: ETAG,
      "Cache-Control": "public, s-maxage=300",
    },
  });
}

In der Praxis werdet ihr das ETag natürlich aus dem Daten-Hash berechnen oder die Versionsnummer des DB-Eintrags verwenden.

6. Stale-While-Revalidate (SWR): schnell und hinreichend frisch

SWR ist der Ansatz „Zeige das alte sofort, lade das neue im Hintergrund“. Man kann ihn umsetzen:

• Auf HTTP-Header-Ebene mit Cache-Control und dem Parameter stale-while-revalidate.
• Auf UI-Ebene mit Bibliotheken wie swr/react-query, die einen lokalen Cache halten und Hintergrund-Refetches durchführen.

SWR im HTTP-Header

Typischer Header:

Cache-Control: public, s-maxage=60, stale-while-revalidate=300

Bedeutung:

• In den ersten 60 Sekunden liefert das CDN die frische Version.
• Von der 61. bis zur 360. Sekunde darf das CDN eine veraltete Antwort sofort liefern und im Hintergrund eine Anfrage an den Origin für die neue Version starten.
• Nach 360 Sekunden wird die Anfrage nach neuem Inhalt blockierend.

Der/die Nutzer:in (und ChatGPT) bekommt die Antwort sofort, sogar bei Lastspitzen, und ihr aktualisiert den Cache im Hintergrund sanft. Für GiftGenius ist das ideal, z. B. für „Top-Sammlungen zu Neujahr“ — sie ändern sich nicht sekündlich.

Beispiel:

// app/api/gifts/top/route.ts
import { NextResponse } from "next/server";

export async function GET() {
  const topGifts = [
    { id: "coffee_mug", title: "Becher mit Aufdruck" },
    { id: "smart_led", title: "Smarte Lampe" },
  ];

  return NextResponse.json(topGifts, {
    headers: {
      "Cache-Control": "public, s-maxage=60, stale-while-revalidate=300",
    },
  });
}

SWR im UI-Widget (React)

Das GiftGenius-Widget läuft in der ChatGPT-Sandbox und kann beliebigen React-Code verwenden. Ihr könnt euren API bereits über window.fetch aufrufen. Fügen wir die Bibliothek swr hinzu und organisieren den Cache auf Widget-Seite:

// widget/GiftTopList.tsx
import useSWR from "swr";

const fetcher = (url: string) => fetch(url).then((r) => r.json());

export function GiftTopList() {
  const { data, isLoading } = useSWR(
    "https://api.giftgenius.com/api/gifts/top",
    fetcher,
    { revalidateOnFocus: false } // im Chat ändert sich der Fokus seltsam, deaktivieren
  );

  if (isLoading && !data) return <div>Ideen werden geladen...</div>;

  return (
    <ul>
      {data?.map((gift: any) => (
        <li key={gift.id}>{gift.title}</li>
      ))}
    </ul>
  );
}

So funktioniert es:

• Beim ersten Render erfolgt ein Request an unseren API.
• Das Ergebnis landet im swr-Cache innerhalb des Widgets.
• Bei erneuten Renders (oder neuen Antworten, in denen ChatGPT das Widget mit demselben Schlüssel erneut einbettet) kommen die Daten aus dem Cache. Der/die Nutzer:in sieht kein „Flackern“ und keine Spinner, während im Hintergrund ein Update laufen kann.

So kombinieren wir zwei SWR-Ebenen:

• Auf CDN/HTTP — um den Origin zu entlasten.
• Im UI — um den/die Nutzer:in zu entlasten.

Wenn man alles zusammenführt:

• Einfaches Cache-Control (max-age/s-maxage) — Basisschicht: Dem CDN und den Clients erlauben, Antworten zu cachen und die Last zu reduzieren.
• ETag + If-None-Match — ergänzen, wenn es wichtig ist, Traffic für große JSONs zu sparen, aber mit einem Netzwerk-Roundtrip zu leben.
• stale-while-revalidate — aktivieren, wenn uns sofortige Auslieferung auch leicht veralteter Daten wichtig ist (Kataloge, Top-Sammlungen).
• SWR im UI (Bibliothek swr/react-query) — eine eigene Schicht, um Widget-Repaints zu glätten und einen lokalen Cache in der ChatGPT-Sandbox zu halten.

7. Was in GiftGenius wie lange cachen

Versuchen wir, die GiftGenius-Daten nach „Cachebarkeitsschichten“ zu ordnen.

Auf CDN/Edge-Ebene cachebar

Alles, was für alle (oder breite Segmente) gleich ist und sich selten ändert:

• Widget-Statik: JS/CSS, Fonts, Icons — quasi „für immer“ (ein Jahr) mit immutable.
• Struktur der Geschenk-Kataloge: Kategorien, Bereiche, Filter — Minuten/Stunden.
• Allgemeine Sammlungen („beste Ideen für Kolleg:innen bis 50 $“) — Minuten/Zehnerminuten, besonders zu Spitzenzeiten.

Hier passt public, s-maxage + stale-while-revalidate ideal.

Besser im Anwendungscode/Redis cachen

Dynamischere, aber dennoch wiederkehrende Daten:

• Ergebnisse schwerer externer APIs (z. B. Wechselkurse, aktuelle Preise aus einem externen Shop).
• Häufig abgefragte Empfehlungsssegmente (nach Geschlecht/Alter/Anlass).

Hier ist das CDN nicht immer geeignet, weil Daten von Token/Organisation/Tenant abhängen können. Wir cachen auf Ebene des MCP-Gateways oder interner REST-Services: voll unter eurer Kontrolle und ohne Datenvermischung zwischen Nutzer:innen.

Nicht cachebar (in Shared-Caches)

Alles, was an eine:n konkrete:n Nutzer:in gebunden ist:

• Persönliche Bestellungen und Bestellstatus.
• Zahlungsinformationen, Adressen, E-Mail.
• Konkrete Empfehlungen auf Basis privater Bestellhistorie (wenn sensibel).

Das kann man nur auf Anwendungsebene mit sorgfältiger Semantik cachen (und ohne Leaks zwischen Nutzer:innen), aber definitiv nicht im public CDN-Cache.

8. Edge-Schicht: CDN vs. Edge-Funktionen

Wichtig, zwei ähnliche, aber unterschiedliche Dinge nicht zu verwechseln:

• CDN / Edge-Cache — hält vorab berechnete Antworten, dort gibt es fast keine Logik.
• Edge-Funktionen (Vercel Edge / Cloudflare Workers) — kleine Code-Snippets, die auf Edge-Knoten laufen.

Die Erfahrung zeigt: Edge ≠ Serverless. Viele Entwickler:innen versuchen, dort schwere Businesslogik, LLM-Calls und BLOB-Verarbeitung unterzubringen und wundern sich dann über Timeouts und Limits. Edge-Funktionen:

• Starten sehr schnell (Cold Start praktisch null).
• Sind aber stark limitiert bzgl. CPU, Laufzeit und verfügbarer APIs (oft ohne vollständiges Node.js, ohne lange Sockets etc.).

Wann eine Edge-Funktion eine gute Idee ist

Im Kontext GiftGenius und ChatGPT App sind Edge-Funktionen nützlich für:

• Leichtes Routing: anhand von Headern wie locale, x-openai-user-location oder Tenant-ID entscheiden, in welchen regionalen Backend-Cluster die Anfrage gehen soll.
• Hinzufügen einfacher Header, Feature-Flags, A/B-Routing.
• Schnelle Read-only-Endpunkte, die Daten aus Edge-KV oder dem CDN-Cache lesen und praktisch nichts berechnen.

Wann eine Edge-Funktion eine schlechte Idee ist

• Lange Anfragen an externe APIs.
• Aufrufe von LLM-Modellen.
• Komplexe Checkout-Logik.
• MCP-Tools mit schwerer Businesslogik.

Für all das habt ihr normale Next.js-Serverless-Funktionen (z. B. runtime = "nodejs") oder gar separate Services/Cluster.

Beispiel einer Edge-Funktion in Next.js 16

Wir erstellen eine kleine Route GET /api/geo-router, die anhand des Headers x-openai-user-location (angenommen) zurückgibt, welchen regionalen Cluster man ansprechen soll.

// app/api/geo-router/route.ts
import { NextRequest, NextResponse } from "next/server";

export const runtime = "edge"; // läuft am Edge

export function GET(req: NextRequest) {
  const userLocation = req.headers.get("x-openai-user-location") ?? "US";
  const cluster =
    userLocation.startsWith("EU") ? "eu-gift-api" : "us-gift-api";

  return NextResponse.json({ cluster }, {
    headers: {
      "Cache-Control": "public, s-maxage=300",
    },
  });
}

So ein Endpunkt:

• Funktioniert sehr schnell (Edge).
• Macht nichts Komplexes.
• Kann vom CDN gecached werden.

9. Edge und Cache in der Gesamtarchitektur von GiftGenius

Fassen wir alles in einer Grafik zusammen.

flowchart TD
    ChatGPT[(ChatGPT / User)]
    CDN["CDN / Edge Cache (Vercel)"]
    EdgeFn["Edge Functions (Routing, Feature-Flags)"]
    GW[MCP Gateway]
    GiftAPI["Gift REST API Cluster"]
    CommerceAPI["Commerce REST API Cluster"]
    DB[(DB/External APIs)]
    
    ChatGPT --> CDN
    CDN -->|Cache-Hit| ChatGPT
    CDN -->|Cache-Miss| EdgeFn
    EdgeFn --> GW
    GW --> GiftAPI
    GW --> CommerceAPI
    GiftAPI --> DB
    CommerceAPI --> DB

Typischer Ablauf:

1. Das ChatGPT-Widget ruft /api/gifts/categories ab.
2. Das CDN prüft den Cache. Wenn dort eine frische oder „stale, aber noch gültige“ Version liegt — liefert es sie sofort aus, ohne EdgeFn/GW zu berühren.
3. Wenn kein Cache-Hit — fällt die Anfrage in EdgeFn (falls aktiv) und/oder direkt in den GW.
4. GW nutzt bei Bedarf einen internen Redis-Cache für schwere Operationen oder ruft interne REST-Services und anschließend die DB auf.
5. Die Antwort geht zurück, landet im CDN/Edge-Cache und wird an andere Nutzer:innen ausgeliefert.

Dieses Setup:

• Reduziert die Latenz für das Widget und ChatGPT.
• Senkt die Last auf MCP-Gateway und Backend-Cluster.
• Verringert die Kosten für LLM-/DB-Aufrufe (weniger Wiederholungsanfragen).

10. Kleine Praxis-Snippets für GiftGenius

Kategorien-Cache + Next.js revalidate

Bisher haben wir nur über API-Endpunkte gesprochen. Aber Next.js bietet ähnliche Mechanismen auch für Seiten — über ISR (revalidate).

Beispiel für eine Server Component, die die Kategorienliste mit revalidate = 60 holt:

// app/(widget)/categories/page.tsx
export const revalidate = 60; // ISR: neu generieren alle 60 Sek.

async function fetchCategories() {
  const res = await fetch("https://api.giftgenius.com/api/gifts/categories");
  return res.json();
}

export default async function CategoriesPage() {
  const categories = await fetchCategories();
  return (
    <ul>
      {categories.map((c: any) => (
        <li key={c.id}>{c.title}</li>
      ))}
    </ul>
  );
}

In Produktion generiert und cached Vercel die HTML-Ausgabe dieser Seite, was nützlich ist, wenn euer Widget/Interface nicht nur über ChatGPT geöffnet wird, sondern auch als normale Webseite (z. B. Debug-Panel oder Landing).

Einfacher Anwendungscache im Backend-Service

Das ist nicht die Edge-Schicht, sondern ein Anwendungscache (Redis/In-Memory innerhalb eurer Gift REST API oder eines anderen Backend-Services). Aber es passt, zu zeigen, wie er im einfachsten Fall aussieht:

// Pseudo-Code innerhalb der Gift REST API
const cache = new Map<string, any>();

async function getGiftCategories() {
  const key = "gift_categories_v1";
  const cached = cache.get(key);
  if (cached && Date.now() - cached.ts < 60_000) {
    return cached.data; // 60 Sekunden Cache
  }
  const data = await fetchRealCategories();
  cache.set(key, { ts: Date.now(), data });
  return data;
}

Im Einsatz ersetzt ihr Map natürlich durch Redis/Memcached, aber die Idee ist dieselbe: seltener zur DB/zum externen API gehen.

Wenn man das auf einen Satz komprimiert: Entscheidet zuerst klar, was man wo cachen kann (CDN, Edge, Redis, DB), und schaltet erst dann die „magischen“ Plattform-Flags ein. Cache ist kein Häkchen in der Konfiguration, sondern Teil der Architektur: Er beeinflusst Geschwindigkeit, Stabilität und Kosten.

11. Typische Fehler beim Arbeiten mit Cache und der Edge-Schicht

Fehler Nr. 1: „Wir cachen alles, Hauptsache schneller“.
Klassiker: Entwickler:in setzt Cache-Control: public, s-maxage=3600 einfach auf alle JSON-Antworten. Nach ein paar Stunden stellt sich heraus, dass ein:e Nutzer:in Bestellungen eines anderen sieht und ChatGPT mit veralteten Verfügbarkeitsdaten arbeitet. Für persönliche oder sensible Daten braucht es entweder einen private-Cache oder man deaktiviert den CDN-Cache ganz und hält den Cache auf Anwendungsebene mit sauberer Isolation.

Fehler Nr. 2: Verwechslung zwischen max-age und s-maxage.
Manche setzen nur max-age und erwarten, dass das CDN genauso lange cached. Tatsächlich bezieht sich max-age primär auf den Browser, für den Shared Cache braucht es s-maxage. Ergebnis: Der Browser cached, das CDN nicht, und der Origin ächzt weiter unter Last — obwohl „Cache gesetzt“ wurde. Der richtige Weg ist, s-maxage fürs CDN explizit anzugeben.

Fehler Nr. 3: Die Erwartung, dass ETag alles schneller macht.
ETag spart hervorragend Traffic, besonders bei großen JSON-Dateien, aber der Netzwerk-Roundtrip bleibt. In der Welt der ChatGPT App heißt das: Das Modell wartet trotzdem auf eine Antwort von eurem Server, wenn auch 304 ohne Body. Wenn euch Latenz wichtig ist, braucht ihr Edge-Cache + SWR; ETag ist ein ergänzender Mechanismus.

Fehler Nr. 4: Schwere Businesslogik in Edge-Funktionen stopfen.
„Lass uns externe LLMs aufrufen, komplexe Sammlungen berechnen und drei externe APIs direkt aus Vercel Edge kontaktieren — das ist doch schnell!“ Danach beginnt der Schmerz: Laufzeitlimits, fehlendes vollwertiges Node.js, merkwürdige Fehler. Edge ist gut für leichtes Routing und A/B, die schwere Arbeit gehört in normale Serverless-Funktionen oder separate Backend-Cluster.

Fehler Nr. 5: Keine Strategie zur Cache-Invalidierung.
Cache „für eine Stunde“ eingerichtet, alles fliegt. Dann sagt das Business: „Wir haben Preise/Kategorien/Einschränkungen geändert, warum sieht in ChatGPT alles noch aus wie zuvor?“ Entwickler:innen beginnen, manuell zu drehen, Caches zu leeren und Services neu zu starten. Für wichtige Daten sollte man vorab planen: Wie wird der Cache invalidiert (per Webhook aus dem Admin, per Version, per Schlüssel) — statt darauf zu hoffen, dass „es sich in einer Stunde schon aktualisiert“.

Fehler Nr. 6: Den Zusammenhang Cache ↔ Kosten ignorieren.
Manchmal denkt man beim Cache nur an Geschwindigkeit. Im LLM-Ökosystem geht es aber auch um Geld: Jeder unnötige Modell-Call und externe API-Call kostet. Ohne Cache kann der MCP-Server externe Services/Modelle so häufig treffen, dass die Monatsrechnung unangenehm überrascht. Richtiges Caching reduziert sowohl Latenz als auch Kosten.

Fehler Nr. 7: Daten verschiedener Sprachen/Regionen im selben Cache mischen.
GiftGenius arbeitet in mehreren Ländern, verwendet aber im Cache einen Schlüssel top_gifts. Ergebnis: Nutzer:in aus den USA sieht Rubel und russische Shops, Nutzer:in aus Europa sieht Dollar und US-Shops. Beim Caching immer Schlüssel wie locale, currency, tenant im Cachenamen berücksichtigen oder im Pfad (z. B. /api/{locale}/gifts/top).

Fehler Nr. 8: Volle Abhängigkeit von der „Magie“ von Next.js/der Plattform.
ISR, revalidate, automatisches CDN — alles großartig. Aber wenn ihr nicht versteht, was unter der Haube passiert, sind Überraschungen vorprogrammiert. Zum Beispiel zeigt die Seite alten Inhalt, während das API neue Daten liefert; ChatGPT sieht das eine, Browser-Nutzer:innen etwas anderes. Es lohnt sich, Zeit zu investieren und zu verstehen, wie Cache-Control, ETag und das SWR-Muster funktionieren — und Next.js als bequemen Wrapper zu nutzen, nicht als Black Box.

Fehler Nr. 9: Keine Unterschiede zwischen Dev/Staging/Production beim Cache.
Im Dev-Umfeld stört Cache oft beim Debuggen („Ich habe die Daten geändert, warum sieht ChatGPT noch alte Sammlungen?“). Sinnvoll ist eine Konfiguration, die im Dev den Cache fast deaktiviert (oder eine TTL von wenigen Sekunden setzt) und in Production aggressives Caching einschaltet. Sonst werdet ihr entweder beim Entwickeln wahnsinnig oder rollt versehentlich ohne Cache in die Produktion und fangt euch eine Flut von Anfragen auf interne Backend-Cluster hinter dem MCP-Gateway.