MCP Gateway: wozu er zwischen ChatGPT und Ihren Services gebraucht wird

1. Warum braucht man überhaupt noch eine weitere Schicht?

Fast alle beginnen gleich: Es gibt einen MCP‑Server, er beschreibt ein paar Tools, ChatGPT spricht direkt per HTTPS mit ihm – und alles scheint prima. Die grobe Architektur sieht so aus:

ChatGPT  →  Ihr MCP-Server  →  Datenbank / externe APIs

In der „Pet‑Project“-Phase ist das tatsächlich eine gute Option. Doch sobald die App mehr Funktionalität bekommt und das Team wächst, treten sehr schnell Probleme zutage.

Erstens wird der MCP‑Server zum „God‑Object“. In ihm leben gleichzeitig die Tools für Geschenk‑Empfehlungen, Checkout, Analytics und noch irgendetwas der Sorte „packen wir die Berichte doch gleich auch noch rein“. Unterschiedliche Codeteile haben unterschiedliche SLAs und Sicherheitsanforderungen, sind aber in einen Prozess geklebt.

Zweitens müssen ChatGPT und andere Clients die Topologie Ihrer Services kennen. Wenn in einem halben Jahr ein weiterer MCP‑Server für Commerce dazukommt, müssen Sie Clients neu anbinden, Konfigurationen und Beschreibungen ändern. Statt einer „einzigen Eintrittsstelle“ entsteht ein URL‑Zoo.

Drittens wird unklar, wo man Dinge umsetzt, die für alle Services gelten: Authentifizierung, Logging, Metriken, Rate Limiting, Token‑Prüfung, Lokalisierung und Routing nach Regionen. Verteilen Sie das auf alle MCP-/Agent‑Services, bekommen Sie viel Duplikation und unterschiedliches Verhalten in verschiedenen Services.

Um diese Kopplung aufzubrechen und die interne Komplexität gleichzeitig vor ChatGPT zu verbergen, kommt das MCP Gateway ins Spiel – ein Netzwerkgateway und eine einheitliche Eintrittsstelle für den gesamten MCP‑Traffic.

2. Was ist ein MCP Gateway im Kontext der ChatGPT-App

Formal ist das MCP Gateway eine Proxy‑Schicht und die einzige Eintrittsstelle zwischen MCP‑Clients (ChatGPT, MCP Jam, Ihre internen Tools) und einem Satz Ihrer Backend‑Services – typischerweise REST/HTTP‑APIs, Microservices, Agents‑Dienste, Commerce‑Backends usw.

Das Gateway implementiert das MCP‑Protokoll nach außen (für ChatGPT wirkt es wie ein einziger MCP‑Server) und spricht innen einfach mit normalen REST‑Endpoints über HTTP/gRPC.

Auf die Anfrage tools/list proxyt das Gateway den Aufruf nicht einfach durch, sondern liefert seine eigene Tool‑Liste: Sie ist entweder fest im Code beschrieben oder wird aus der Konfiguration zusammengestellt. Jedes Tool ist an einen konkreten REST‑Endpoint und ein Datenschema gebunden. Auf tools/call nimmt das Gateway den Tool‑Namen, findet die passende REST‑Route und ruft sie über fetch/HTTP‑Client auf.

Schematisch lässt sich das so darstellen:

flowchart LR
    ChatGPT["ChatGPT / Modell"] --> |MCP JSON-RPC| Gateway["MCP Gateway<br/>(einziger MCP-Server)"]
    Gateway --> GiftAPI["Gift REST API<br/>/ Geschenk-Microservice"]
    Gateway --> CommerceAPI["Commerce REST API<br/>/ ACP / Zahlungen"]
    Gateway --> AnalyticsAPI["Analytics Service<br/>/ Events und Metriken"]

Für ChatGPT ist es ein einzelner Server: eine URL, ein Satz von Tools, ein Event‑Stream. Für Sie ist es ein flexibler Routing‑Punkt für Traffic zu verschiedenen kalten und heißen Services.

3. MCP Gateway in der GiftGenius-Architektur

Um weniger abstrakt zu bleiben und das Gateway „in einem lebenden System“ zu zeigen, setzen wir das GiftGenius‑Beispiel fort – eine App, die Geschenke empfiehlt und Bestellungen über ACP/Instant Checkout abwickeln kann.

In der einfachen Version hatten wir einen MCP‑Server, der sowohl suggest_gifts als auch checkout_start konnte. Jetzt, da die App gewachsen ist, trennen wir die Zuständigkeiten:

• Gift REST API – Suche und Empfehlungen für Geschenke, Arbeit mit Katalog und Feed (normaler HTTP/REST‑Service).
• Commerce REST API – ACP, Checkout‑Sessions, Bestellstatus, Anbindung an den Payment‑Provider.
• Analytics Service / REST API – Erfassung von Events und Metriken (welche Empfehlungen geöffnet werden, was gekauft wird).
• Eigener Agents‑Service (falls nötig) – komplexe mehrstufige Szenarien. Er ist ebenfalls über HTTP/REST erreichbar, nicht über MCP.

Das MCP Gateway wird zur einzigen Eintrittsstelle für all diese Komponenten. Es:

• liefert auf tools/list eine einheitliche Tool‑Liste, die es selbst beschreibt: Jedes Tool ist an einen konkreten REST‑Endpoint eines der Services gebunden;
• schaut auf tools/call auf den Tool‑Namen (params.name), bestimmt per Routing‑Tabelle, zu welchem REST‑Service es gehen soll, und ruft die passende HTTP‑Methode auf (via fetch, axios etc.).

Kommt ein tools/call mit dem Namen suggest_gifts, ruft das Gateway den entsprechenden REST‑Endpoint in der Gift REST API auf. Bei checkout_start geht die Anfrage an die Commerce REST API.

Kleiner TypeScript‑Pseudocode im Express‑Stil könnte so aussehen:

// Sehr vereinfachter Handler für MCP-Anfragen
app.post("/mcp", async (req, res) => {
  const mcpReq = req.body as { method: string; params?: any };
  const ctx = buildContextFromHeaders(req); // Auth, Locale usw.

  const toolName = mcpReq.params?.name;
  const backendRes = await callBackend(toolName, mcpReq, ctx);

  res.json(backendRes);
});

Innerhalb von pickBackend können Sie sich auf den Methodennamen, den Tool‑Namen, die Locale des Nutzers und sogar auf die Serviceversion stützen (für „Canary“- und Blue/Green‑Releases, über die wir später im Modul sprechen).

4. Aufgaben des MCP Gateway: Was es definitiv macht

Wir haben gesehen, wie sich das Gateway in die GiftGenius‑Architektur einfügt. Jetzt halten wir explizit fest, welche Aufgaben es als eigene Schicht unabhängig von der konkreten App hat. Wichtig ist, das Gateway als Netzwerk‑ und Cross‑Service‑Schicht zu begreifen. Seine Aufgabe ist es nicht, über Geschenk‑Businesslogik nachzudenken, sondern die Infrastrukturthemen darum herum zu lösen.

Anfragen-Routing

Die erste Rolle ist die eines Routers. Das Gateway erhält eine MCP‑Anfrage und wählt anhand ihres Inhalts, des Benutzerkontexts und seiner Konfiguration den Zielservice aus.

Beispiel: In GiftGenius kann man eine einfache Routing‑Tabelle anlegen:

const TOOL_ROUTES: Record<string, "gift" | "commerce" | "analytics"> = {
  suggest_gifts: "gift",
  get_similar_gifts: "gift",
  checkout_start: "commerce",
  get_order_status: "commerce",
  log_event: "analytics",
};

Und dann so benutzen:

function pickBackend(req: McpRequest, ctx: GatewayContext): Backend {
  if (req.method === "tools/list") return "aggregator";
  if (req.method === "tools/call") {
    const toolName = req.params?.name;
    const group = TOOL_ROUTES[toolName] ?? "gift";
    return group === "commerce" ? commerceBackend : giftBackend;
  }
  return giftBackend;
}

In unserem Fall sind giftBackend, commerceBackend, analyticsBackend normale REST‑Services: Jeder hat eine Basis‑URL ("https://gift-api.internal", "https://commerce-api.internal", …). Das Gateway tunnelt MCP nicht nach innen weiter, sondern zerlegt den MCP‑Aufruf in eine HTTP‑Anfrage an den passenden REST‑Endpoint.

Authentifizierung und Autorisierung am Perimeter

Die zweite Schlüsselaufgabe ist der Perimeterschutz. Das Gateway ist ein guter Ort, um das Token zu prüfen, festzustellen, wer der Nutzer ist, zu welcher Organisation er gehört und welche Berechtigungen er hat.

Es kann zum Beispiel ein OAuth‑Token von ChatGPT oder von Ihrem MCP‑Auth‑Server entgegennehmen, es validieren (vorzugsweise mit einer bewährten Bibliothek statt mit eigener Kryptografie) und in ein sauberes Kontextobjekt verwandeln:

type GatewayContext = {
  userId: string | null;
  tenantId: string | null;
  locale: string;
};

function buildContextFromHeaders(req: Request): GatewayContext {
  const token = req.headers["authorization"]; // "Bearer ..."
  const claims = token ? verifyJwt(token) : null;

  return {
    userId: claims?.sub ?? null,
    tenantId: claims?.tenant ?? null,
    locale: (req.headers["x-openai-locale"] as string) || "en-US",
  };
}

Die internen Backend-/REST‑Services müssen sich dann nicht mit rohen HTTP‑Headern und Tokens herumschlagen, sondern erhalten bereits einen normalisierten context mit userId, tenantId und locale. Die MCP‑Doku empfiehlt ausdrücklich: Validieren Sie Tokens nicht „from scratch“, sondern nutzen Sie bewährte Bibliotheken und kurzlebige Tokens.

Logging, Tracing und Metriken

Die dritte Rolle ist Observability. Das Gateway sieht alle eingehenden MCP‑Anfragen und alle Antworten – ideal, um eine Correlation‑ID zu setzen, Tool‑Parameter (ohne sensible Daten) zu loggen, Antwortzeit und Status zu erfassen.

Eine einfache Idee:

app.use((req, res, next) => {
  const requestId = crypto.randomUUID();
  (req as any).requestId = requestId;

  const start = Date.now();
  res.on("finish", () => {
    const ms = Date.now() - start;
    console.log(
      `[${requestId}] ${req.method} ${req.url} -> ${res.statusCode} in ${ms}ms`
    );
  });

  next();
});

Später im Observability‑Modul können Sie diese Daten nicht nur in console.log schreiben, sondern in ein strukturiertes Storage senden und Dashboards darauf bauen.

Grundlegende Lastkontrolle

Viertens – ebenfalls wichtig – die primäre Lastkontrolle. Am Gateway ist es bequem, Zähler pro Nutzer, Organisation, Tool und Endpoint zu setzen, damit ein „wildgewordener“ Client nicht Ihren Cluster und das Modellbudget verbrennt.

In diesem Modul halten wir zunächst die Idee fest: Rate Limiting und Queues leben auf der Gateway‑Ebene, die Implementierungsdetails (Redis, Token Bucket, Leaky Bucket) besprechen wir in der nächsten Vorlesung zum Perimeterschutz.

Anreicherung von Anfragen mit Kontext

Und schließlich ist das Gateway ein guter Ort, um den rohen Kontext des MCP‑Clients in saubere Argumente für die internen Tools zu verwandeln.

ChatGPT kann zum Beispiel die Locale des Nutzers über openai/locale und _meta["openai/userLocation"] übergeben. Das Gateway kann:

• den passenden regionalen Service auswählen (ru‑Server, en‑Server etc.);
• locale zu den Tool‑Argumenten hinzufügen, auch wenn das Tool es nicht explizit im JSON‑Schema angefordert hat (z. B. als optionales Feld).

Sinngemäß:

function enrichToolArgs(args: any, ctx: GatewayContext) {
  return {
    ...args,
    locale: args.locale ?? ctx.locale,
    tenantId: ctx.tenantId,
  };
}

So erhält das Gift API sofort „reichen Kontext“ und kann beispielsweise russische Beschreibungen für "ru-RU" und englische für "en-US" laden.

5. Was der MCP Gateway NICHT tun sollte

Wenn Entwickler ein „magisches Nadelöhr“ haben, durch das alles läuft, ist die Versuchung groß, dort alles unterzubringen, was vorher in eigenen Services lag. So droht das Gateway zum Monster zu werden.

Es gibt einige Dinge, die in der Regel nicht in diese Schicht gehören.

Erstens: komplexe Businesslogik. Geschenk‑Empfehlungen, Rabattregeln, Versandkostenberechnung, ACP‑Logik – all das sollte in spezialisierten Backend-/Commerce‑Services bleiben. Das Gateway kann höchstens leichte Vorvalidierung machen (z. B. prüfen, dass der Preis nicht negativ ist), aber keine SKUs auswählen oder Steuern pro Region berechnen.

Zweitens: lang lebender Benutzerzustand. Das Gateway ist typischerweise ein stateless Service. Es sollte horizontal skalieren, sich nicht auf lokalen Speicher verlassen und ohne Folgen neu starten können. Wenn Sie dort z. B. den Zustand eines Checkout‑Wizards oder den temporären Warenkorb speichern, bekommen Sie schnell Synchronisationsschmerzen zwischen Instanzen.

Drittens: spezifische Funktionen, die sinnvoller in den Backend‑Services selbst liegen (Gift API, Commerce API). Wenn das Gift‑Backend Suchergebnisse cachen will, soll es das selbst tun – vielleicht mit Redis. Das Gateway muss diese interne Optimierung nicht kennen. Wir sprechen separat noch über Perimeterschutz; dort betonen wir: Das Gateway ist für Netzwerk‑ und Cross‑Service‑Funktionen da, nicht für die Empfehlungsregeln.

Viertens: schwere Berechnungen. Wenn Sie im Gateway anfangen, LLM‑Modelle aufzurufen, komplexe Transformationen und Aggregationen zu machen, wird es vom „leichten“ Front zur dicken Backend‑Schicht, die schwer zu skalieren und zu debuggen ist.

6. Gateway, Lokalisierung und Serviceversionen

Wir haben die Basisaufgaben des Gateways und No‑Gos besprochen. Schauen wir jetzt auf zwei typische „fortgeschrittene“ Aufgaben, die sich in dieser Schicht besonders gut lösen lassen: Lokalisierung und Versionierung von Services. Eine weitere interessante Rolle des Gateways ist smartes Routing nach Locale und Serviceversionen.

Wenn ChatGPT Ihre App aufruft, kennt es bereits die Sprache des Nutzers (openai/locale) und häufig auch seine Geolocation (_meta["openai/userLocation"]). Das Gateway kann diese Information nutzen, um Anfragen an die passenden Backend‑Services zu schicken.

Man kann zum Beispiel eine Architektur „ein Gateway – viele einsprachige Backend‑Server“ bauen:

• ru‑Gift API – nur russischer Geschenkkatalog und Texte.
• en‑Gift API – nur englisch.
• jp‑Gift API – japanisch (wenn Sie die Weltherrschaft anstreben).

Das Gateway tritt in diesem Fall als MCP‑Server für ChatGPT auf und wählt anhand von locale und userLocation den passenden internen Service.

Sinngemäß:

function pickGiftBackendByLocale(ctx: GatewayContext): Backend {
  if (ctx.locale.startsWith("ru")) return giftRuBackend;
  if (ctx.locale.startsWith("ja")) return giftJpBackend;
  return giftEnBackend;
}

Gleich dort lässt sich auch einfaches Canary‑Routing umsetzen. In diesem Modul zur Production‑Architektur empfehlen wir, das Gateway zu nutzen, um einen Teil des Traffics an einen neuen Service‑Cluster zu senden, den Rest an den alten.

Ein sehr grobes Canary‑Beispiel:

function pickGiftBackendCanary(ctx: GatewayContext): Backend {
  const hash = hashUser(ctx.userId ?? "anonymous");
  const bucket = hash % 100;
  return bucket < 5 ? giftBackendV2 : giftBackendV1; // 5% des Traffics gehen an v2
}

So können Sie eine neue Version des Gift API sicher ausrollen, Metriken und Fehler beobachten, ohne den gesamten Prod sofort zu brechen.

7. Typische Architekturen: von „alles in einem“ zum Gateway

Früher im Kurs haben Sie bereits mehrere Varianten der Production‑Architektur einer ChatGPT‑App gesehen. In diesem Modul heben wir drei Basistopologien hervor, die in 90 % der Fälle ausreichen.

Die erste ist „alles in einem“. App‑Widget (Next.js), MCP‑Server, Agents‑Logik und ein einfacher Commerce‑Backend leben in einem Service, oft in einem Repository und sogar in einer einzigen Vercel‑App. Vorteil: kaum DevOps, einfacher Deploy, minimale Latenz. Nachteil: einzelne Hot‑Features lassen sich schwer isoliert skalieren, ein heißes Feature kann die gesamte App lahmlegen, und die Grenzen zwischen Komponenten sind unscharf.

Die zweite: App + MCP Gateway + mehrere Backend‑Services. Hier lebt das Next.js‑Widget separat (z. B. auf Vercel), und der gesamte MCP‑Traffic läuft über das Gateway, das Anfragen an Gift REST API, Commerce REST API, den Agents‑Dienst, das ACP‑Backend usw. routet. Das ist genau das Schema, das wir im Rahmen von GiftGenius betrachten – und es passt für 90 % realer Production‑Fälle.

Die dritte ist dasselbe, aber in mehreren Regionen (Multi‑Region), mit einem globalen Load‑Balancer vor dem Gateway. Nutzer aus Europa landen im eu‑Cluster, aus den USA im us‑Cluster, und jede Region ist nach dem Schema „Gateway + mehrere Backend‑Services“ aufgebaut. Das ist bereits etwas für größere Projekte mit globalem Publikum.

Wichtig ist jetzt weniger, sich alle Varianten zu merken, sondern das Gateway als eigene logische Architekturkomponente zu denken – auch wenn seine Rolle anfangs z. B. ein MCP‑Monolith oder das Backend Ihrer App übernimmt.

8. Wo MCP Gateway physisch läuft

Gute Nachricht: Ein MCP Gateway muss kein riesiger eigener Service auf Kubernetes sein. Meist durchläuft es mehrere Reifestufen.

Im kleinsten Maßstab kann der MCP‑Server selbst die Rolle des Gateways übernehmen. Dann sollten Sie den Code sauber strukturieren: Routing, Authentifizierung und Logging in ein Modul auslagern, die Tool‑Logik in andere. In diesem Modul betonen wir ausdrücklich, dass in kleinen Systemen Gateway‑Funktionen innerhalb des MCP‑Servers oder des Backend‑Teils der App (z. B. in einer Next.js‑API‑Route) liegen können.

Der nächste Schritt ist ein eigener Node/TypeScript‑Service. Das kann eine Express/Fastify‑App sein, die "/mcp" lauscht und intern mehrere HTTP‑Services aufruft. Für viele Teams ist das ein komfortabler Weg: Er passt gut zu gewohnten DevOps‑Werkzeugen.

Ein einfachstes Skelett eines solchen Services:

const app = express();
app.use(express.json());

app.post("/mcp", handleMcpRequest); // hier passiert die gesamte Gateway-Magie

app.listen(4000, () => {
  console.log("MCP Gateway listening on :4000");
});

Auf einer reiferen Stufe kann man das Gateway auf Managed‑Lösungen aufsetzen: AWS API Gateway, Cloudflare Workers/Routes, NGINX/Envoy mit Routing‑Konfiguration und Lua/JS‑Skripten. Wichtig: Das ist eine Änderung der Implementierung, nicht des Konzepts. Architektonisch spricht ChatGPT weiterhin mit einem Punkt, und alle Details erledigt das Gateway.

9. Mini-Beispiel: ein einfacher MCP Gateway für GiftGenius

Wir haben bereits Routing, Kontext und die Behandlung von tools/list separat betrachtet. Jetzt fassen wir alles in einem kleinen, aber klaren Beispiel zusammen. Angenommen, wir haben zwei interne REST‑Services:

• GIFT_API_BASE = "https://gift-api.internal";
• COMMERCE_API_BASE = "https://commerce-api.internal".

Und ein Gateway, das für ChatGPT unter "https://gateway.giftgenius.com/mcp" erreichbar ist.

Zuerst definieren wir ein paar Typen:

type Backend = "gift" | "commerce";

type ToolRoute = {
  backend: Backend;
  method: "GET" | "POST";
  path: string;
};

const TOOL_ROUTES: Record<string, ToolRoute> = {
  suggest_gifts: {
    backend: "gift",
    method: "POST",
    path: "/api/gifts/suggest",
  },
  checkout_start: {
    backend: "commerce",
    method: "POST",
    path: "/api/checkout/start",
  },
  get_order_status: {
    backend: "commerce",
    method: "GET",
    path: "/api/orders/status",
  },
};

Als Nächstes implementieren wir die Backend‑Auswahl und den Aufruf:

async function callBackend(toolName: string, mcpReq: McpRequest, ctx: GatewayContext) {
  const route = TOOL_ROUTES[toolName];
  if (!route) {
    throw new Error(`Unknown tool: ${toolName}`);
  }

  const base =
    route.backend === "gift" ? GIFT_API_BASE : COMMERCE_API_BASE;

  const url = base + route.path;

  // Args, die im MCP-Aufruf tools/call angekommen sind
  const args = {
    ...(mcpReq.params?.arguments ?? {}),
    locale: ctx.locale,
  };

  const res = await fetch(url, {
    method: route.method,
    headers: { "content-type": "application/json" },
    body: route.method === "POST" ? JSON.stringify(args) : undefined,
  });

  const data = await res.json();

  // Antwort des REST-Services in eine MCP-Antwort einpacken
  return {
    result: data,
  } satisfies McpResponse;
}

Und schließlich der Haupt‑Handler, der:

1. den Kontext aus den Headern aufbaut (Auth, Locale);
2. das Backend auswählt;
3. entweder tools/list aggregiert oder tools/call proxyt.

app.post("/mcp", async (req, res) => {
  const mcpReq = req.body as McpRequest;
  const ctx = buildContextFromHeaders(req);

  if (mcpReq.method === "tools/list") {
    // Das Gateway deklariert Tools und ihre Schemas selbst
    const tools = [
      {
        name: "suggest_gifts",
        description: "Wählt Geschenke nach Budget und Interessen aus.",
        inputSchema: { /* ... JSON Schema ... */ },
      },
      {
        name: "checkout_start",
        description: "Erstellt einen Bestellentwurf und startet den Checkout.",
        inputSchema: { /* ... */ },
      },
      // ...
    ];

    return res.json({ result: { tools } });
  }

  if (mcpReq.method === "tools/call") {
    const toolName = mcpReq.params?.name;
    const backendRes = await callBackend(toolName, mcpReq, ctx);
    return res.json(backendRes);
  }

  res.status(400).json({ error: { message: "Unsupported MCP method" } });
});

Das ist natürlich eine vereinfachte Skizze, zeigt aber bereits die Kernideen:

• Das Gateway weiß nicht, wie das Gift API Geschenke empfiehlt;
• es routet lediglich sauber, reichert Argumente an und loggt bzw. limitiert die Aufrufe nach Bedarf.

10. Wie das alles mit den weiteren Themen des Moduls zusammenhängt

Das MCP Gateway ist der Grundbaustein für alles, was wir in den verbleibenden Vorlesungen des Moduls besprechen:

• In der nächsten Einheit geht es um Perimeterschutz: Rate Limiting, Queues und Backpressure. All das lebt primär auf Gateway‑Ebene, weil es den gesamten eingehenden Traffic sieht und „Überflüssiges abschneiden“ kann, bevor Anfragen die Backends überlasten.
• Dann sprechen wir über Resilienz: Timeouts, Circuit Breaker, Bulkheads. Das Gateway ist der Punkt, an dem sich Timeouts für externe Aufrufe zentral setzen und problematische Services ein-/ausschalten lassen (z. B. Commerce API temporär „abschalten“, wenn sie in Fehler läuft).
• Schließlich betrachten wir beim Thema Skalierung und Deploy das Gateway als eigenen Cluster, den man load‑balancen, per Blue/Green und Canary ausrollen und unabhängig von den internen MCP‑Services zurückrollen kann.

Im Grunde: Wenn Sie bisher dachten „ich habe eine App und einen MCP‑Server“, erweitert sich das Bild zu „ich habe eine App, ein MCP Gateway, mehrere Backend-/Agents‑Cluster und ein Commerce‑Backend“. Und gerade das Gateway sorgt dafür, dass die ChatGPT‑Konfiguration nicht komplizierter wird – es sieht weiterhin eine einzige MCP‑Stelle.

11. Typische Fehler beim Arbeiten mit dem MCP Gateway

Fehler Nr. 1: das Gateway in ein „Business‑Monster“ verwandeln.
Häufige Falle: Weil alles durch das Gateway läuft, warum nicht Rabattberechnungen, SKU‑Auswahl, komplexe Kategorieregeln oder Promo‑Code‑Validierung dorthin packen? Am Ende entsteht ein fetter Service, der sich schwer skalieren und ändern lässt – und der Sinn der Aufteilung in Gift API, Commerce API und andere spezialisierte Komponenten geht verloren. Besser das Gateway als dünne Netzwerkschicht halten und alles Domänenspezifische in den Fachservices belassen.

Fehler Nr. 2: lang lebenden Benutzerzustand im Gateway speichern.
Die Idee „lassen wir den Warenkorb des Nutzers direkt im Gateway‑Speicher“ klingt verlockend, solange es nur eine Instanz gibt. Sobald eine zweite dazukommt, beginnt der Schmerz: Wo ist der echte Warenkorb – Instanz A oder B? Was passiert nach einem Neustart? Das Gateway sollte stateless bleiben: maximal ein kleiner Cache für Handshakes oder Configs, aber Sitzungs- und Bestellzustand liegen in der DB oder in spezialisierten Services.

Fehler Nr. 3: ChatGPT über die interne Service‑Topologie informieren.
Wenn Sie ChatGPT mehrere API‑Server direkt geben (separat Gift API, separat Commerce API) und das Gateway nur „manchmal“ nutzen, verlieren Sie den Hauptvorteil: den einheitlichen Einstieg und die zentrale Kontrolle. Bei Topologiewechseln müssen mehrere Stellen angepasst werden. Viel einfacher ist es, das MCP Gateway einmal als offiziellen Endpoint für die App zu konfigurieren und alle internen Änderungen dahinter zu verbergen.

Fehler Nr. 4: Cross‑Service‑Logik in allen Backends duplizieren.
Manche Teams versuchen, Authentifizierung, Rate Limiting, Logging und Lokalisierung in jedem REST‑Service getrennt zu implementieren. Ergebnis: Die Rechte‑ und Limit‑Policy ist in der Gift API eine, in der Commerce API eine andere – und das App‑Verhalten wird unvorhersehbar. Genau dafür gibt es das Gateway: Token prüfen, Tenant und Locale bestimmen, den Aufruf loggen, Limits anwenden – und dann in den konkreten Service gehen.

Fehler Nr. 5: das Gateway mit schweren Berechnungen und LLM‑Aufrufen überladen.
Technisch spricht nichts dagegen, aus dem Gateway noch ein LLM aufzurufen, komplizierte Aggregationen oder lange Batch‑Operationen zu machen. Aber so wird es schnell zu einem weiteren schweren Backend, das sich kaum sauber skalieren und isolieren lässt. Das Gateway sollte schnell und vorhersagbar bleiben: maximal leichte Transformation und Routing. Alles Schwere gehört in die REST‑Services oder in Queues/Worker, über die wir später sprechen.

Fehler Nr. 6: die Infrastruktur zu früh verkomplizieren.
Die Gegenposition: sofort ein eigenes Kubernetes‑Cluster, NGINX‑Stack, Cloudflare Workers und jede Menge komplexer Configs für eine kleine Lern‑App. Das lohnt sich nicht, solange keine reale Last und Verfügbarkeitsanforderungen bestehen. Es ist vollkommen okay, mit einem MCP‑Monolithen oder einem einfachen Node‑Gateway zu starten und erst mit wachsender Größe einzelne Komponenten in Cluster und Managed‑Services auszulagern.