Skalierung und Deployment: Lastverteilung, Cluster von Backend‑Services, Blue/Green und Canary

1. Worum es in dieser Vorlesung überhaupt geht und warum das wichtig ist

Stellen Sie sich vor, Sie haben GiftGenius an dem Punkt gelassen, an dem es einsam auf Vercel lebt: eine einzelne Instanz des MCP‑Gateways (das nach außen MCP spricht und gleichzeitig Ihre REST‑Services aufruft), ein Backend für Agents, alles „funktioniert irgendwie“. Das ist für ein Pet‑Projekt und die ersten 100 Nutzer noch vertretbar.

Sobald OpenAI Ihre App jedoch in den Store aufnimmt und sie plötzlich vor Weihnachten in die Startauswahl gerät, wird „ein Gateway auf Port 3000“ zur traurigen Geschichte: Warteschlangen von Tool‑Aufrufen, Timeouts, 500er‑Fehler, sinkendes Rating im Store und Mails vom Marketing à la „warum lag alles im Peak der Verkäufe?“.

Unsere Aufgabe in dieser Vorlesung ist es, GiftGenius (und jede ChatGPT App) als System aus vielen identischen Instanzen hinter einem Load Balancer zu denken. Außerdem klären wir saubere Release‑Strategien und ein klares Schema dafür, „wie man zurückrollt, wenn etwas schiefgeht“.

2. Horizontale Skalierung und Stateless‑Design

Beginnen wir mit der Grundidee: Wenn Ihr MCP Gateway oder ein interner Backend‑Service wichtigen Zustand im Speicher eines konkreten Prozesses hält, lässt sich dieser praktisch nicht sinnvoll horizontal skalieren.

Vertikale vs. horizontale Skalierung

Zuerst klären wir die Terminologie.

Vertikale Skalierung – Sie „pumpen“ einfach einen Server auf: mehr CPU, mehr RAM. Das geht schnell, ist am Anfang manchmal günstig, hat aber eine harte Grenze und macht eine Instanz zum single point of failure: Fällt dieses starke Monster aus, fällt alles aus.

Horizontale Skalierung – Sie starten mehrere Exemplare des Services hinter einem Load Balancer. Jede Instanz ist relativ klein, hält keinen kritischen Zustand im RAM, und Zustand liegt in externen Speichern (Postgres, Redis, Object Storage). Instanzen können je nach Last frei hinzugefügt und entfernt werden.

Für MCP Gateway und Backend‑Services (Gift REST API, Commerce REST API, Analytics Service / REST API usw.) ist horizontale Skalierung de facto Pflicht: ChatGPT kann Ihnen plötzlich viel mehr Traffic schicken (Saison, Store‑Promo, ein virales TikTok), und Sie sollten einfach Instanzen hinzufügen, statt „zu beten, dass ein Server durchhält“.

Was ist ein Stateless‑Service im Kontext von MCP Gateway und Backends

Damit horizontale Skalierung funktioniert, sollte der Service so weit wie möglich stateless sein.

Stateless bedeutet in unserem Kontext:

• Der Service hält im Speicher kein einzigartiges, langlebiges Benutzer‑State, von dem die Business‑Logik abhängt;
• jeder wichtige Zustand liegt in einer externen DB, Queue, einem Cache oder einem S3‑ähnlichen Speicher;
• wenn eine konkrete Instanz ausfällt, kann eine andere den Nutzer weiter bedienen, indem sie den Kontext einfach aus dem externen Speicher „aufnimmt“.

Für GiftGenius heißt das:

• die Historie der Geschenkempfehlungen des Nutzers, seine Likes/Dislikes und der Warenkorb liegen z. B. in Postgres;
• Queues für langlaufende Aufgaben (massengenerierte Empfehlungen, E‑Mail‑Versand) liegen in einem Broker wie Redis/Cloud Queue;
• wenn es einen separaten Service für komplexe Agent‑Workflows gibt, speichert er Checkpoints und langlebigen Speicher in seinem Store, nicht im RAM eines einzelnen Prozesses.

Eine Instanz des MCP Gateways oder eines beliebigen Backend‑Services wird zur „Kuh statt Haustier“: Man kann sie ohne Reue töten und neu erzeugen, ohne Business‑Daten zu verlieren.

Mini‑Beispiel: Zustand aus dem Speicher in ein externes Repository verlagern

Stellen wir uns vor, Sie haben irgendwann ein sehr einfaches MCP‑Tool add_to_cart gebaut, das über das Gateway interne Logik aufruft, die den Warenkorb im Prozessspeicher hält (ja, so macht man es manchmal in Demos – und das ist okay, solange Sie verstehen, dass das in Prod nicht geht):

// SCHLECHT: Warenkorb im Arbeitsspeicher des Backend-Service-Prozesses
const inMemoryCarts = new Map<string, string[]>();

export async function addToCart(userId: string, sku: string) {
  const cart = inMemoryCarts.get(userId) ?? [];
  cart.push(sku);
  inMemoryCarts.set(userId, cart);
  return cart;
}

Horizontale Skalierung ist hier unmöglich: Eine Anfrage landet auf Instanz A, eine andere auf Instanz B, und der Nutzer hat unterschiedliche Warenkörbe.

Der richtige Ansatz ist, den Warenkorb in eine externe DB oder einen Cache auszulagern. Vereinfacht:

// GUT: Warenkorb in einem externen Speicher
import { db } from "./db";

export async function addToCart(userId: string, sku: string) {
  await db.cartItems.insert({ userId, sku }); // vereinfacht
  const cart = await db.cartItems.findMany({ where: { userId } });
  return cart;
}

Jetzt ist es egal, welche Instanz des Backend‑Services die Anfrage verarbeitet, die über das Gateway kam: Der Warenkorb ist für alle gleich.

3. Lastverteilung: wie Traffic in die Cluster der Backend‑Services gelangt

Sobald es mehr als eine Instanz eines Services gibt, braucht es jemanden, der Anfragen zwischen ihnen verteilt. Das ist wie der Disponent in einer beliebten Pizzeria: Viele Kuriere, viele Kunden – ohne Logik herrscht Chaos.

L4 vs. L7 und warum uns vor allem L7 interessiert

Ein Load Balancer kann auf verschiedenen Ebenen arbeiten:

• L4 (TCP/UDP) leitet schlicht Byte‑Ströme vom Client an ein Backend weiter, ohne das Protokoll zu verstehen;
• L7 (HTTP) versteht, dass es sich um eine HTTP‑Anfrage handelt, kann auf Pfad, Header, Cookies und manchmal sogar auf den Body schauen.

Für die ChatGPT‑App‑Architektur mit MCP Gateway und REST‑Services brauchen wir fast immer einen L7‑Load Balancer: Alles spricht HTTP/SSE, und wir wollen nach Pfad, Domain, Headern (z. B. für Canary‑Releases) routen und Health‑Checks machen.

Health‑Checks und „kranke“ Instanzen aus der Rotation nehmen

Der Load Balancer sollte regelmäßig prüfen, ob Instanzen leben. Am einfachsten ist ein GET‑Endpoint /health oder /readyz, der 200 OK zurückgibt, wenn alles gut ist.

In einem Node/TypeScript‑Service, der als MCP Gateway oder Backend arbeitet, könnte der Health‑Check so aussehen:

// apps/gateway/src/http/health.ts
import { type Request, type Response } from "express";

export function healthHandler(req: Request, res: Response) {
  res.json({
    status: "ok",
    version: process.env.RELEASE_ID ?? "dev",
  });
}

Der Load Balancer pingt alle N Sekunden /health. Wenn Antworten mit 5xx kommen oder in den Timeout laufen, wird die Instanz aus der Rotation entfernt und neuer Traffic nicht mehr dorthin gesendet.

Besonderheiten für Streaming / SSE

Das MCP Gateway arbeitet recht häufig über SSE (Server‑Sent Events), besonders wenn Sie das Streaming von Teilresultaten nutzen. Der Load Balancer sollte:

• langlaufende HTTP‑Verbindungen unterstützen;
• solche Verbindungen bei der Instanzwahl berücksichtigen (manche LBs berücksichtigen die Anzahl aktiver Verbindungen, nicht nur RPS).

Das ist wichtig, weil ein „geschwätziger“ Tool‑Aufruf, der 2 Minuten Text streamt, als aktive Verbindung hängt. Wenn auf einer Instanz zu viele solche Verbindungen laufen, sollte diese Instanz vorübergehend „entlastet“ werden – neue Verbindungen gehen dann zu anderen.

4. Backend‑Service‑Cluster: nach Aufgaben trennen statt alles in einen Topf

Der logische nächste Schritt ist, nicht mehr an einen „großen Backend‑Service“ zu denken, sondern das System je nach Lastcharakter und Kritikalität in mehrere Cluster aufzuteilen.

Beispielarchitektur von GiftGenius nach Clustern

Die in Modul 16 gesammelten Bausteine empfehlen für GiftGenius folgendes Schema:

Im Kern ist das das bulkheads‑Pattern (Schotten): Wenn Cluster B plötzlich „CPU mit Tokens verbrennt“ bei der Generierung komplexer Texte, arbeitet Cluster C für die Zahlung weiter, weil er seinen eigenen Ressourcenpool und seine eigene Skalierung hat.

Wie das durch den Gateway aussieht

Das im ersten Vortrag des Moduls beschriebene MCP Gateway sieht den gesamten eingehenden MCP‑Traffic und routet ihn auf Backend‑Cluster. Ungefähr so:

• Tool‑Aufrufe list_gifts, suggest_gifts → Cluster A (Gift REST API);
• Tool‑Aufrufe generate_greeting_card oder komplexe Agent‑Workflows → Cluster B (Agents‑REST‑Service oder Worker);
• Tools create_order, confirm_payment → Cluster C (Commerce REST API).

Dahinter kann bereits ein gemeinsamer Load Balancer oder mehrere Load Balancer stehen (z. B. ein separater L7‑LB vor Commerce, um noch stärker zu isolieren).

Man kann das so skizzieren:

flowchart LR
    ChatGPT((ChatGPT))
    GW[MCP Gateway]
    LBA[LB Gift API Cluster A]
    LBB[LB Agents/Workers Cluster B]
    LBC[LB Commerce API Cluster C]

    A1[Gift REST API A-1]
    A2[Gift REST API A-2]
    B1[Agents Service B-1]
    B2[Agents Service B-2]
    C1[Commerce REST API C-1]
    C2[Commerce REST API C-2]

    ChatGPT --> GW
    GW -->|tools: gifts| LBA
    GW -->|agents workflows| LBB
    GW -->|commerce| LBC

    LBA --> A1
    LBA --> A2
    LBB --> B1
    LBB --> B2
    LBC --> C1
    LBC --> C2

Die Skizze ist leicht idealisiert, spiegelt aber das Prinzip wider: unterschiedliche Lasttypen – unterschiedliche Backend‑Cluster hinter einem MCP Gateway.

5. Deploy‑Strategien: warum Blue/Green und Canary wichtig sind

Kommen wir nun dazu, wie man das alles aktualisiert, ohne dass Nutzer etwas merken – und Sie nachts ruhig schlafen können.

Anti‑Beispiel: Deployment „über den laufenden Prod“

Die einfachste und gefährlichste Strategie: Sie nehmen den laufenden Cluster (z. B. Gift REST API A), starten das neue Image über dem alten, ersetzen Container oder starten Prozesse neu.

Probleme dabei:

• während ein Teil der Instanzen bereits neu und ein Teil noch alt ist, kann sich das System unvorhersehbar verhalten (besonders, wenn sich das DB‑Schema geändert hat);
• wenn etwas schiefgeht, ist der Rollback ein erneutes Deployment des alten Zustands, was Minuten dauern kann;
• im Moment des Deployments kann es gut einen kurzen Downtime geben, wenn noch keine Instanz wieder oben ist.

In Kubernetes und PaaS wird das durch Rolling‑Updates etwas entschärft, aber die Idee ist dieselbe: Ohne klare Strategie gibt es viel „Grauzone“, in der verschiedene Code‑Versionen gleichzeitig Traffic verarbeiten.

Blue/Green‑Deployment: zwei Umgebungen und sofortiges Umschalten

Blue/Green ist ein Ansatz, bei dem es gleichzeitig zwei fast identische Umgebungen gibt: Blue (aktueller Prod) und Green (neue Version).

Schematisch sieht der Prozess so aus:

1. Sie rollen die neue Version (v2) in der Green‑Umgebung aus: derselbe Satz aus Gateway + Backend‑Clustern, nur noch ohne echten Traffic.
2. Sie führen in Green alle nötigen Tests aus: Autotests, Smoke‑Szenarien, manuelle Checks über den ChatGPT Dev Mode.
3. Zum Release‑Zeitpunkt schalten Sie im Load Balancer/Routing so um, dass 100% des echten Traffics zu Green gehen.
4. Blue läuft daneben als „Ausweichflugplatz“ weiter. Wenn etwas schiefgeht, schalten Sie in Sekunden zurück.

Für GiftGenius könnte das so aussehen: Es gibt mcp-gateway-blue.example.com und mcp-gateway-green.example.com. Die ChatGPT App im Prod zeigt auf den offiziellen MCP‑Endpoint (Gateway), und beim Release ändern Sie die DNS/LB‑Konfiguration so, dass der Domain‑Name mcp-gateway.example.com bereits auf Green zeigt.

Vorteile:

• sofortiges Umschalten in beide Richtungen;
• jedes Problem kann nach dem Rollback in Ruhe behoben werden;
• keinen Zustand „halb neu, halb alt“ im Cluster.

Nachteile:

Während des Releases müssen zwei vollständige Umgebungen vorgehalten werden, Ressourcen also ×2. Daher nutzt man diese Strategie meist für kritische Backend‑Services – z. B. den Commerce‑Cluster C und das MCP Gateway selbst, wo Checkout und Entry‑Point unter keinen Umständen kaputtgehen dürfen.

Canary‑Releases: der kleine Kanarienvogel in der Kohlenmine

Ein Canary‑Release ist die kostengünstigere Variante: Sie fahren die neue Version schrittweise für einen kleinen Teil des Traffics aus und beobachten sie genau.

Beispielszenario:

1. Sie deployen Version v2 des Gift REST API‑Clusters A in denselben Pool oder in einen kleinen Canary‑Pool.
2. Sie konfigurieren den Load Balancer oder das MCP Gateway so, dass z. B. 1% der Tool‑Aufrufe rund um Geschenke an v2 gehen und 99% an v1.
3. Sie beobachten Metriken: Error‑Rate, Latenz, spezifische Business‑Metriken (Conversion, erfolgreiche Checkouts).
4. Wenn alles gut ist, erhöhen Sie den Anteil schrittweise: 1% → 5% → 10% → 50% → 100%. Wenn nicht – sofort zurückrollen.

Im Kontext von ChatGPT Apps ist Canary nicht nur für Code nützlich, sondern auch für Experimente mit Prompts: Eine neue Version des System‑Prompts für den Agent‑Service kann das Verhalten radikal ändern – besser erst auf einer kleinen Nutzerstichprobe testen.

Gateway oder LB können festlegen, welche Anfrage „canary“ ist, anhand von:

• Zufall (z. B. 1% aller Anfragen);
• userId (ein Teil der Nutzer landet dauerhaft im Experiment);
• einem speziellen Header oder Cookie (für internes Testen).

Ein kleines Beispiel für Routing‑Logik in pseudo‑TypeScript (zur Veranschaulichung im Gateway):

// Pseudocode im Gateway: einfacher zufälliger Canary 5%
function routeToGiftBackendCluster(ctx: { userId?: string | null }) {
  const rnd = Math.random();
  if (rnd < 0.05) {
    return "gift-api-v2"; // canary
  }
  return "gift-api-v1";   // stable
}

In der Praxis machen Sie das natürlich nicht via Math.random() im Runtime‑Code, sondern legen Regeln in Config/Feature‑Flags ab – die Logik bleibt aber ähnlich: Ein Teil des Traffics geht an die Canary‑Version des Backend‑Services, der Rest an die stabile.

6. Rollback als zwingender Teil der Strategie

Ich habe mir vor langer Zeit eine gute Regel gemerkt: Rollback muss schneller sein als Fix.

Heißt: Wenn nach dem Release die Fehler hochgehen und Nutzer schreiben „es bricht alles“, reparieren Sie nicht heroisch live in Prod. Drücken Sie den großen roten Knopf „Rollback“.

Auf Plattformen wie Vercel (auf denen wir bereits den Next.js‑Teil von GiftGenius ausgerollt haben) ist das sehr naheliegend: Jeder Deploy ist ein unveränderliches Artefakt, und Vercel erlaubt den schnellen Rollback auf den vorherigen.

Für MCP Gateway und Backend‑Cluster, die in Kubernetes oder einem anderen Orchestrator laufen, übernimmt das kubectl rollout undo: Sie rollen auf den vorherigen Satz Pods/Images zurück.

Wichtig ist: Versionen loggen und anzeigen, die gerade Traffic bedienen. Beispielsweise können Sie:

• version in /health und andere diagnostische Endpoints aufnehmen (haben wir oben schon getan);
• die Release‑ID über Header in die Logs geben (z. B. X-Release-Id).

Mini‑Beispiel: eine Next.js‑API‑Route, die die Build‑Version für die Inspektion der ChatGPT App innerhalb eines Widgets zurückgibt:

// apps/web/app/api/version/route.ts
export async function GET() {
  return Response.json({
    version: process.env.RELEASE_ID ?? "dev",
    builtAt: process.env.BUILT_AT ?? "unknown",
  });
}

So ein Endpoint hilft auch beim Debuggen: Sie können die produktive Instanz fragen, welche Version gerade läuft, statt zu raten „ist der letzte Build wirklich live?“.

7. Capacity Planning: wie viele Instanzen braucht GiftGenius

Wir haben besprochen, wie man sicher neue Versionen ausrollt (Blue/Green, Canary) und bei Problemen schnell zurückrollt. Bleibt die praktische Frage: Wie viele Instanzen welcher Cluster braucht es in Prod, damit das echte Traffic aushält und Sie nicht in die Kostenfalle laufen?

Ohne Formelfanatismus, aber ein bisschen sollte sein. Skalierung muss mit Last und Wirtschaftlichkeit verknüpft sein: Wie viele Anfragen am Tag/Sekunde, wie viele schwere LLM‑Aufrufe, was kostet das pro Tag.

Zur Vereinfachung in Größenordnungen denken:

• bei 10k Anfragen pro Tag (etwa 0.1 RPS im Schnitt) kommen Sie leicht mit ein bis zwei Instanzen des MCP Gateways und ein paar Instanzen von Gift REST API/Agents‑Workern aus;
• bei 100k Anfragen pro Tag (1–2 RPS im Schnitt, in Peaks mehr) sollten Sie bereits 3–5 Instanzen für Gateway + Gift REST API‑Cluster haben, einen separaten Cluster B für schwere Agents und einen dedizierten Commerce‑Cluster;
• bei 1M Anfragen pro Tag (zweistellige RPS, Peak‑Lasten an Feiertagen) brauchen Sie sicher Cluster, dedizierte Ressourcen für LLM‑Agents, aggressives Caching und eine Edge‑Schicht (dazu gibt es eine eigene Vorlesung).

Das sind keine strengen Zahlen, sondern dazu da, Sie zu einer groben Lastabschätzung zu bringen: Wo sind die Engpässe, wie skalieren Sie, und was kostet es.

Für GiftGenius ist die Vorbereitung auf Feiertage besonders wichtig: Neujahr, Weihnachten, Valentinstag, Black Friday. Die Last kann um ein Vielfaches steigen – und das System sollte das wegstecken.

8. Praktisches Mini‑Beispiel: die Evolution des Deployments von GiftGenius

Um alles zusammenzuführen, zeichnen wir eine einfache Evolution des GiftGenius‑Deployments.
Hier wenden wir nacheinander alles an, worüber wir oben gesprochen haben: Stateless‑Design von Gateway und Backend‑Services, Lastverteilung, getrennte Cluster und Release‑Strategien (Blue/Green, Canary).

Basisebene: ein Gateway + Backend auf Vercel/Kubernetes

Irgendwann im Kurs haben Sie das bereits gebaut: eine Next.js‑App mit Apps SDK auf Vercel, in der sowohl der MCP‑Endpoint als auch einfache Backend‑Logik (Gift/Commerce) in einem Service leben. Ziemlich monolithisch.

Vorteile sind klar: einfach, günstig, wenige Stellen, an denen man Fehler machen kann.

Der Nachteil ist genau einer, aber kritisch: Das skaliert nicht für ernsthaften Traffic und verträgt Updates schlecht.

Stufe 2: separater MCP Gateway + mehrere Backend‑Cluster

Nächster Schritt:

• Sie trennen das MCP Gateway in einen eigenen Service (Node/Go/NGINX+Lua, egal);
• Sie starten mehrere Instanzen der Gift REST API (Cluster A) und mehrere Worker/Services für Agents (Cluster B);
• für Commerce richten Sie einen separaten Service ein (Cluster C), eventuell auf eigener DB/Infra.

Hier kommen bereits klassische L7‑Lastverteilung, Health‑Checks und möglichst horizontale Skalierung zum Einsatz.

Stufe 3: Release‑Strategien

Auf dieser Stufe ergänzen Sie:

• Blue/Green für den Commerce‑Cluster C (und bei Bedarf für das MCP Gateway), damit Checkout und Authentifizierung maximal stabil bleiben;
• Canary‑Releases für die Cluster der Gift REST API und des Agent‑Services, um entspannt mit neuen Versionen von Tools und Agents zu experimentieren, ohne den gesamten Prod zu riskieren.

Schematisch:

flowchart LR
    ChatGPT((ChatGPT))
    GWBlue[Gateway Blue]
    GWGreen[Gateway Green]
    LB[Traffic Switch]

    subgraph Prod
      LB --> GWBlue
      LB -.canary,% .-> GWGreen
    end

    ChatGPT --> LB

In der Realität kann es etwas komplexer sein (separates Blue/Green nur für Commerce, Canary nur für Gift‑Cluster), aber die Idee wird klar: Sie wissen stets, welche Version wohin geht, und für ChatGPT sieht es weiterhin wie ein einziger MCP‑Entry‑Point (Gateway) aus.

9. Kleine Code‑Schnipsel für Versionierung und Diagnostik

Wir haben den Health‑Endpoint und /api/version bereits gesehen. Fügen wir noch ein Beispiel hinzu, wie man Version und Cluster im Handler eines MCP‑Tools auf Gateway‑Seite loggen kann, um Metriken später leicht zu korrelieren.

Stellen wir uns das Tool suggest_gifts vor, das als REST‑Endpoint in der Gift REST API implementiert ist und über das Gateway aufgerufen wird:

import { type McpToolHandler } from "@modelcontextprotocol/sdk";

export const suggestGifts: McpToolHandler<{
  occasion: string;
  budget: number;
}> = async ({ input, meta }) => {
  const releaseId = process.env.RELEASE_ID ?? "dev";
  const clusterId = process.env.CLUSTER_ID ?? "gift-api-A";

  console.log("[suggest_gifts]", {
    releaseId,
    clusterId,
    userId: meta.userId,
    occasion: input.occasion,
  });

  // Hier ruft das MCP Gateway anhand der Routing-Tabelle die Gift REST API auf,
  // und das Tool selbst bleibt eine dünne Hülle über dem REST-Aufruf
  return {
    content: [{ type: "text", text: "Gift ideas..." }],
  };
};

Hier:

• lesen wir RELEASE_ID und CLUSTER_ID aus den Umgebungsvariablen;
• schreiben sie in strukturierte Logs;
• lassen sich diese später leicht zur Analyse nutzen: „auf welcher Version/in welchem Cluster haben wir gerade die höhere Fehlerquote?“.

Für die ChatGPT App ist das völlig transparent, für Sie als Entwickler jedoch ein großer Pluspunkt – besonders in Kombination mit Canary/Blue‑Green.

10. Typische Fehler beim Skalieren und Deployen einer ChatGPT App

Fehler Nr. 1: Sitzungs-/Benutzerzustand im Speicher des Gateways oder Backend‑Prozesses halten.
Dieser Ansatz zerstört die horizontale Skalierbarkeit: Sobald eine zweite Instanz hinzukommt, „schichtet“ sich der Zustand zwischen ihnen auf. Besonders gefährlich ist es, Warenkorb, Suchergebnisse oder Workflow‑Fortschritt im RAM zu halten. All das gehört in externe Speicher – DB, Cache oder einen spezialisierten Store für Agent‑State.

Fehler Nr. 2: zu glauben, „ein starker Server“ reicht aus.
Vertikale Skalierung ist am Anfang bequem, funktioniert beim realen Wachstum aber schlecht: Die Maschine hat physische Grenzen, ein Prozess wird zum Single Point of Failure, und ChatGPT kann unvorhersehbare Traffic‑Spitzen bringen. Für MCP Gateway und Backend‑Cluster braucht es fast immer stateless‑Design und mehrere Instanzen hinter einem Load Balancer.

Fehler Nr. 3: neue Versionen „über Prod“ ausrollen ohne klare Strategie.
Wenn Sie Container/Prozesse im produktiven Cluster einfach aktualisieren, erhalten Sie einen Zwischenzustand, in dem ein Teil des Traffics zur alten Version geht und ein Teil zur neuen, und beim Fehler wird der Rollback zum „nochmal deployen“. Viel zuverlässiger ist es, entweder zwei Umgebungen zu halten (blue/green) oder zumindest eine canary‑Version des Backend‑Services zu haben, auf die nur ein kleiner Teil des Traffics geht.

Fehler Nr. 4: kein schneller Rollback‑Plan.
Schlechtes Szenario: Release durch, Metriken rot, Nutzer beschweren sich – und Sie fangen erst an zu überlegen, wie man zurückrollt. Richtiges Szenario: vorab vorbereitete Möglichkeit zum sofortigen Rollback (Blue/Green‑Schalter, rollout undo, Vercel‑Rollback), klare Versions‑IDs in Logs und Health‑Endpoints und die harte Regel „erst zurückrollen, dann analysieren“.

Fehler Nr. 5: ein gemeinsamer Cluster „für alles“ ohne Trennung nach Lasttypen.
Wenn die Generierung von Glückwunschtexten (LLM‑Agents) und der Checkout im selben Cluster leben, kann jedes Problem auf Modellseite (Latenzen, Timeouts, Tokenanstieg) auch die Zahlung lahmlegen. Die Trennung in Cluster nach Aufgabentypen (Gift REST API / leichte Tools, Agents‑Heavy‑Service, Commerce REST API) und separate Limits/Ressourcen je Cluster sind ein wichtiger Schritt zur Resilienz.

Fehler Nr. 6: keine Verbindung zwischen Architektur und Wirtschaftlichkeit.
Es ist leicht, sich mit „heben wir noch zwei Nodes“ mitreißen zu lassen und zu vergessen, dass jeder LLM‑Aufruf und jede Instanz Geld kostet. Ohne einfachstes Capacity Planning (Last‑ und Kostenabschätzung) kann man entweder zu wenig skalieren und Prod crashen – oder zu viel skalieren und die Marge verlieren. Hier hilft es, Anzahl Anfragen, Anteil schwerer LLM‑Operationen und Hosting‑Kosten mit den Business‑Metriken der Anwendung zu verknüpfen.