Systemresilienz: Timeouts, Circuit Breakers, Bulkheads, Schutz vor Webhook-Stürmen

1. Warum überhaupt über „Resilienz“ in der ChatGPT App nachdenken

In einer normalen Webanwendung sieht der Nutzer wenigstens die URL, den Browser-Spinner und kann die Seite neu laden. In ChatGPT sieht der Nutzer einen Bildschirm: den Chat und Ihre App. Wenn etwas langsam ist, unterscheidet er nicht, wer schuld ist — OpenAI, Ihr Gateway, der Zahlungsdienst oder der Analytics-Microservice nebenan. Für ihn ist das alles „ChatGPT + Ihre App“.

Wenn ein tool-call 30–60 Sekunden hängt, wartet das Modell, wartet … und entschuldigt sich im besten Fall für die Verzögerung. Im schlechtesten halluziniert es eine Antwort statt der Daten aus Ihrem Backend. Resilienz ist daher nicht nur ein Thema für SRE und Uptime, sondern ebenso für Antwortqualität, Tonalität des Modells und Metriken im Store.

Im Ökosystem der ChatGPT App haben wir mehrere unabhängige Ketten:

• ChatGPT ↔ MCP Gateway.
• Gateway ↔ Ihre Backend-/REST-Services (Gift REST API, Commerce REST API, Analytics Service usw.).
• Ihre Services ↔ externe APIs (LLM, Zahlungen, Kataloge).
• Eingehende Webhooks (ACP, Stripe, beliebige Integrationen) ↔ Ihre Handler.

Das Problem ist, dass ein Ausfall an einer Stelle einen Dominoeffekt auslösen kann: Das Gateway wartet brav auf einen hängenden Service, Worker stauen sich, Verbindungen gehen aus, Clients starten Retries, und nach ein paar Minuten haben Sie das klassische „BEL-System“: Alles brennt und sinkt gleichzeitig. Genau davor schützen uns die vier Muster, über die wir heute sprechen:

• Timeouts – wir warten niemals ewig.
• Circuit breaker – wir rennen nicht gegen verschlossene Türen.
• Bulkheads – wir bauen „Schotten“ und lassen nicht das ganze Schiff sinken.
• Schutz vor Stürmen von Webhooks – wir akzeptieren, dass Webhooks mit Duplikaten, Peaks und Retries kommen, und bereiten uns darauf vor.

2. Timeouts: Wir warten nicht ewig

Was ist ein Timeout und warum ist es ohne ihn problematisch

Ein Timeout ist die maximale Zeit, die Ihr Code bereit ist, auf eine Antwort einer Abhängigkeit zu warten: Datenbank, MCP-Server, externes HTTP-API, Modell. Kommt innerhalb der Zeit keine Antwort, gilt der Aufruf als fehlgeschlagen, wir geben Ressourcen frei und liefern einen verständlichen Fehler oder einen Fallback zurück.

Ohne Timeouts können Anfragen:

• unendlich hängen bleiben,
• Verbindungen und Thread-/Worker-Pools blockieren,
• nachfolgende Anfragen blockieren,
• Kaskadenausfälle verursachen.

Das Muster ist einfach: „Lieber ein vorhersehbarer Abbruch nach 3–5 Sekunden als unerklärliche Stille für 5 Minuten.“

Wichtig ist, dass wir Timeouts auf mehreren Ebenen haben:

• auf Ebene von Proxy/Load Balancer (Cloudflare, Nginx),
• auf Ebene des MCP Gateway (HTTP-Clients zu Microservices),
• in den Services selbst (Aufrufe zur DB, zu externen APIs, LLM).

Für ChatGPT ist es insgesamt sinnvoll, die gesamte Zeit eines tool-call im Bereich von 5–10 Sekunden für übliche Operationen und maximal 20–30 Sekunden für besonders schwere zu halten. Alles, was länger dauert, führt fast garantiert zu schlechtem UX.

Einfaches fetchWithTimeout in TypeScript

Fangen wir mit der Praxis an. Im GiftGenius MCP Gateway gibt es einen Hilfs-HTTP-Client, der den Geschenke-Empfehler, den Commerce-Service und die Analytics aufruft. Wir umschließen das Standard-fetch mit einer Funktion, die ein Timeout setzt:

// src/gateway/httpClient.ts
export async function fetchWithTimeout(
  url: string,
  opts: RequestInit & { timeoutMs?: number } = {}
) {
  const { timeoutMs = 5000, ...rest } = opts;
  const controller = new AbortController();
  const timeoutId = setTimeout(() => controller.abort(), timeoutMs);

  try {
    return await fetch(url, { ...rest, signal: controller.signal });
  } finally {
    clearTimeout(timeoutId);
  }
}

Nun machen wir im Gateway-Code niemals ein „nacktes“ fetch, sondern nur über diesen Helper:

// src/gateway/giftClient.ts
import { fetchWithTimeout } from "./httpClient";

export async function callGiftService(path: string) {
  const res = await fetchWithTimeout(
    process.env.GIFT_SERVICE_URL + path,
    { timeoutMs: 4000 }
  );

  if (!res.ok) {
    throw new Error(`gift_service_${res.status}`);
  }
  return res.json();
}

Dieser Ansatz garantiert, dass wir – selbst wenn der Gift-Service hängt – nach 4 Sekunden die Verbindung abbrechen und einen MCP-Fehler an ChatGPT zurückgeben, anstatt die Verbindung bis zum Anschlag zu halten.

Wo genau Timeouts in GiftGenius gesetzt werden sollten

In unserem GiftGenius-Beispiel:

• Auf Gateway-Ebene: Timeouts für Aufrufe an Gift REST API, Commerce REST API, Analytics Service / REST API.
• Innerhalb dieser Services: Timeouts für Aufrufe zur Datenbank, ACP/Zahlungsdiensten, externen Empfehlungs-APIs.
• Am Eingang des Gateways: ein globales Timeout für die Anfrage von ChatGPT, damit ein tool-call nicht zum „ewigen Spinner“ wird.

Wichtig ist, dass die Wartezeit auf der oberen Ebene etwas größer ist als die auf den inneren Ebenen. Wenn z. B. das Gateway den Backend 5 Sekunden wartet und der Backend die DB 3 Sekunden wartet, haben wir Puffer für Verarbeitung und Serialisierung des Ergebnisses.

Wie man Timeouts dem ChatGPT-Modell erklärt

Für ChatGPT ist es wichtig, semantische Fehler zurückzugeben, nicht stumm Verbindungen fallen zu lassen. Anstelle eines abstrakten 500 ist es besser, einen strukturierten MCP-Fehler zu liefern, den das Modell dem Nutzer kommunizieren kann: „Der Geschenk-Empfehlungsservice ist gerade überlastet, versuche es später noch einmal“ usw.

Das bedeutet, dass das Gateway bei einem Timeout Folgendes tun sollte:

1. AbortError oder unseren timeout_… abfangen.
2. Eine MCP-Antwort mit sinnvollem Code und kurzer Beschreibung formen.
3. Dem Modell die Möglichkeit geben zu entscheiden, wie es das einem Menschen erklärt.

Timeouts lösen das Problem hängender Anfragen, aber wenn eine Abhängigkeit massenhaft ausfällt, schützen sie nicht vor einer Lawine identischer Fehlversuche. Hier brauchen wir die nächste Schutzebene – den Circuit Breaker.

3. Circuit breaker: der „Automat“ gegen sterbende Services

Intuition: warum ein einzelnes Timeout nicht reicht

Wir begrenzen bereits die Wartezeit einzelner Aufrufe mittels Timeouts. Ein Timeout schützt einen konkreten Call. Aber wenn eine Abhängigkeit „hart“ ausfällt (z. B. stürzt der Commerce-Service bei jeder Anfrage mit OOM (Out Of Memory) ab), werden wir ihn weiter aufrufen, jedes Mal 3–5 Sekunden warten, den Fehler fangen, Netzwerk und CPU belasten und wieder warten.

Ein Circuit Breaker fügt Gedächtnis hinzu: Er verfolgt Fehler und Timeouts und wenn es zu viele werden, schickt er überhaupt keine Anfragen mehr an diesen Service. Stattdessen liefert er sofort einen schnellen Abbruch oder einen Fallback. Nach einiger Zeit probiert er vorsichtig wieder im Modus half-open.

Klassische Zustände des Automaten:

• Closed – alles normal, Anfragen werden gesendet.
• Open – der Service gilt als „tot“, Anfragen werden nicht gesendet, sofort Fehler.
• Half-open – wir probieren eine begrenzte Zahl von Anfragen; wenn sie erfolgreich sind, zurück zu closed, bei erneuten Fehlern wieder open.

Einfache Circuit-Breaker-Skizze

Kleine Diagramm-Skizze:

stateDiagram-v2
    [*] --> Closed
    Closed --> Open: zu viele Fehler
    Open --> HalfOpen: Cooldown abgelaufen
    HalfOpen --> Closed: mehrere Erfolge hintereinander
    HalfOpen --> Open: erneut Fehler
    Open --> Open: schneller Abbruch

Mini-Implementierung eines Circuit Breakers in TypeScript

Im Produktivbetrieb nutzt man meist fertige Bibliotheken (für Node.js z. B. opossum oder leichte Self-Made-Lösungen), aber um die Mechanik zu verstehen, reicht eine kompakte Klasse.

Beispiel eines stark vereinfachten Breakers um einen Commerce-Aufruf:

// src/gateway/circuitBreaker.ts
type State = "closed" | "open" | "half-open";

export class CircuitBreaker {
    private state: State = "closed";
    private failureCount = 0;
    private nextAttemptAt = 0;

    constructor(
        private readonly failureThreshold = 5,
        private readonly cooldownMs = 30_000
    ) {}

    async call<T>(fn: () => Promise<T>): Promise<T> {
        const now = Date.now();

        if (this.state === "open") {
            if (now < this.nextAttemptAt) {
                throw new Error("circuit_open");
            }
            this.state = "half-open";
        }

        try {
            const result = await fn();
            this.onSuccess();
            return result;
        } catch (err) {
            this.onFailure();
            throw err;
        }
    }

    private onSuccess() {
        this.failureCount = 0;
        this.state = "closed";
    }

    private onFailure() {
        this.failureCount++;
        if (this.failureCount >= this.failureThreshold) {
            this.state = "open";
            this.nextAttemptAt = Date.now() + this.cooldownMs;
        }
    }
}

Und die Verwendung im Commerce-Client:

// src/gateway/commerceClient.ts
const commerceBreaker = new CircuitBreaker(3, 20_000);

export async function callCommerce(path: string) {
    return commerceBreaker.call(async () => {
        const res = await fetchWithTimeout(
            process.env.COMMERCE_URL + path,
            { timeoutMs: 3000 }
        );
        if (!res.ok) throw new Error(`commerce_${res.status}`);
        return res.json();
    });
}

Wenn Commerce massenhaft Fehler liefert oder nicht rechtzeitig antwortet, wechselt der Breaker nach einigen Fehlschlägen in den Zustand open. In diesem Zustand versuchen wir während cooldownMs gar nicht erst, den Service aufzurufen, und liefern sofort den Fehler circuit_open.

Was ChatGPT sehen sollte, wenn der Breaker den Service „abgeschaltet“ hat

Aus Sicht von ChatGPT ist es besser, wenn Sie:

• schnell mit einem MCP-Fehler wie „commerce_unavailable“ oder „gift_service_overloaded“ antworten,
• eine verständliche Beschreibung hinzufügen: „Der Zahlungsservice ist vorübergehend nicht verfügbar, versuchen wir es später noch einmal“,
• den Fehler nicht hinter endlosen Retries verstecken.

Das ist genau der Fall, in dem ein „schneller, ehrlicher Abbruch“ besser ist als langes Hängen. Besonders im Checkout: Der Nutzer akzeptiert eher eine ehrliche Meldung, als 40 Sekunden auf einen Spinner zu schauen und „Etwas ist schiefgelaufen“ zu erhalten.

Timeouts und Breaker schützen uns vor „schlechten“ oder ausgefallenen Abhängigkeiten, aber sie lösen nicht das Problem, wenn eine Lastart alle Ressourcen frisst und andere Teile des Systems erstickt. Dafür brauchen wir eine weitere Schicht – Bulkheads.

4. Bulkheads: Isolierte „Schotten“, damit nicht alles sinkt

Schiffs-Analogie

Das Bulkhead-Muster ist nach den Schotten in einem Schiff benannt: Wenn in einem Abteil ein Leck ist, verteilt sich das Wasser nicht auf das ganze Schiff. In der Architektur heißt das: Ressourcen trennen zwischen verschiedenen Arbeitsrichtungen, damit ein überlasteter Service nicht alles – CPU, Verbindungen, Pools – aufbraucht und kritische Pfade lahmlegt.

In Microservices erreicht man das typischerweise über getrennte:

• HTTP-Verbindungspools,
• Thread-/Worker-Pools,
• Queues/Topics,
• sogar separate DB-Cluster für kritisch wichtige Operationen.

Die Idee ist, dass wenn der Geschenk-Empfehlungsservice langsamer wird und klemmt, er nur seine Ressourcen aufbraucht, aber den Checkout und die Authentifizierung nicht mitreißt.

Bulkheads in der Welt von Node.js und MCP Gateway

In Node.js haben wir keine Threads im klassischen Sinne (es gibt den Event Loop und Worker), aber wir können die Anzahl paralleler Tasks pro Richtung begrenzen.

Beispiel: Im Gateway gibt es drei externe Abhängigkeiten:

• Gift-Service (Geschenkempfehlung, schwere LLM-Aufrufe).
• Commerce-Service (Checkout, ACP).
• Analytics-Service (Ereignisprotokollierung).

Wir können einfache Limits für gleichzeitige Anfragen an jede davon einführen.

Zum Beispiel ein kleiner „Semaphore“ zur Begrenzung der Parallelität:

// src/gateway/bulkhead.ts
export class Bulkhead {
    private active = 0;
    private queue: (() => void)[] = [];

    constructor(private readonly maxConcurrent: number) {}

    async run<T>(fn: () => Promise<T>): Promise<T> {
        if (this.active >= this.maxConcurrent) {
            await new Promise<void>((resolve) => this.queue.push(resolve));
        }
        this.active++;

        try {
            return await fn();
        } finally {
            this.active--;
            const next = this.queue.shift();
            if (next) next();
        }
    }
}

Und die Verwendung für Services:

// src/gateway/clients.ts
import { Bulkhead } from "./bulkhead";

const giftBulkhead = new Bulkhead(10);      // bis zu 10 parallel
const commerceBulkhead = new Bulkhead(3);   // Checkout stark begrenzt
const analyticsBulkhead = new Bulkhead(50); // hier geht viel

export async function callGiftWithBulkhead(fn: () => Promise<any>) {
    return giftBulkhead.run(fn);
}

export async function callCommerceWithBulkhead(fn: () => Promise<any>) {
    return commerceBulkhead.run(fn);
}

So werden – selbst wenn GPT beschließt, „mach mir 30 komplexe Geschenkempfehlungen“ – diese maximal 10 gleichzeitig ausgeführt, während der Checkout weiterarbeiten kann und sein eigenes Limit nutzt.

GiftGenius: Welche Schotten wollen wir

Für GiftGenius ist es sinnvoll, separate Schotten für Folgendes zu schaffen:

• Geschenkempfehlung (LLM-schwer, weniger kritisch, darf langsamer sein),
• Checkout/ACP (hoch-kritisch, maximal zu schützen),
• Analytics/Logs (wichtig, aber geringe Verzögerungen sind tolerierbar).

In einer weiterentwickelten Architektur deployen Sie sie sogar als unterschiedliche Cluster mit separaten Ressourcen. Im Rahmen dieser Vorlesung ist aber die Idee entscheidend: Nebensächlichen Features nicht erlauben, den gesamten „Sauerstoff“ zu verbrauchen.

Diese drei Muster – Timeouts, Circuit Breaker und Bulkheads – betreffen, wie Sie nach außen zu Ihren Abhängigkeiten sprechen. Es gibt jedoch noch eine andere Klasse von Resilienz-Bedrohungen: eingehende Ereignisströme, die Sie auch bei perfekt konfigurierten ausgehenden Aufrufen überrollen können. Das typischste Beispiel sind Webhook-Stürme.

5. Webhook-Stürme: wenn die Außenwelt schneller Events schickt, als Sie verarbeiten können

Wie sich Webhooks in der Realität verhalten

Die vierte Problemquelle für Resilienz sind eingehende Events: Webhooks von ACP, Stripe und anderen Systemen. Gerade sie können einen echten „Sturm“ auslösen, selbst wenn Sie Timeouts, Circuit Breaker und Bulkheads schon eingerichtet haben.

Webhooks sind keine HTTP-„Pull“-Requests, sondern „Push“-Events von externen Systemen (Stripe, ACP, externe Shops usw.). Sie haben einige unangenehme Eigenschaften:

• Lieferung mindestens einmal (at-least-once) – Duplikate sind unvermeidbar.
• Die Lieferreihenfolge ist nicht garantiert.
• Bei Fehlern wird gern geretryt: erst nach einer Sekunde, dann nach 10, dann nach einer Minute … bis Sie 2xx antworten.
• In Peaks (z. B. bei Sales) kommen sie in Batches und erzeugen einen „Sturm“.

Wenn Ihr Handler nicht idempotent ist und zu lange arbeitet, wird er zum Flaschenhals, die gesamte Queue staut sich, und Retries verstärken den Sturm nur. Am Ende können Sie DB, Queue, Worker-Pools – und in der Kette den Rest des Systems – in die Knie zwingen.

Grundprinzipien des Sturmschutzes

Einige Ideen erhöhen die Überlebenschancen im Sturm erheblich:

Erstens: queue-first, process-later. Idealerweise sollte ein eingehender Webhook keine schwere Arbeit synchron ausführen. Stattdessen validiert er so schnell wie möglich Signatur/Format, legt einen Task in die Queue und antwortet mit 200 OK. Die Verarbeitung läuft asynchron in einem Worker. Wenn Sie „schnelle Bestätigungen“ für ChatGPT brauchen, können Sie einen separaten Benachrichtigungspfad betreiben.

Zweitens: Idempotenz des Handlers. Ein wiederholter Webhook zur gleichen Operation sollte nicht „die Bestellung erneut anlegen“ oder „Geld doppelt abbuchen“. Üblicherweise löst man das über einen Idempotency Key oder ein eventId und die Prüfung, ob wir dieses Event bereits verarbeitet haben.

Drittens: Rate Limiting und Circuit Breaker am Empfänger. Selbst wenn der Sender stürmt, können Sie:

• RPS nach IP/Subscription/Endpoint begrenzen,
• vorübergehend 429 oder 503 liefern, um Retries zu verlangsamen,
• einen Breaker nutzen, um keinen Strom in ein kaputtes Downstream-System (z. B. Bestell-DB) zu kippen.

Beispiel eines Next.js-Webhook-Handlers in GiftGenius

Angenommen, wir haben einen ACP/Zahlungsdienst, der einen Webhook zum Bestellstatus an POST /api/commerce/webhook schickt. Wir wollen:

• das Event schnell annehmen und in eine Queue legen,
• es nicht synchron verarbeiten,
• nicht an Duplikaten zerbrechen.

Vereinfachtes Beispiel (ohne Signaturprüfung und echte Queue – das kommt in den Modulen zu Sicherheit und Queues):

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

// Hier könnten wir Redis/eine Queue haben; vorerst simulieren wir ein Array
const inMemoryQueue: any[] = [];
const processedEvents = new Set<string>(); // Idempotenz (für Demo)

export async function POST(req: NextRequest) {
    const event = await req.json();

    const eventId = event.id as string;
    if (processedEvents.has(eventId)) {
        return NextResponse.json({ ok: true, duplicate: true });
    }

    // In der Realität gäbe es hier Signatur- und Schema-Prüfung

    inMemoryQueue.push(event); // in die Queue für die Hintergrundverarbeitung legen
    // Ein Hintergrund-Worker verarbeitet später und markiert die ID als verarbeitet
    return NextResponse.json({ ok: true });
}

Das ist noch eine Pseudo-Implementierung, aber zwei Punkte sind wichtig:

1. Der synchrone Teil ist so leicht wie möglich.
2. Wir bauen Idempotenz rund um event.id ein.

In der Realität werden Sie:

• eine externe Queue (SQS, RabbitMQ, Kafka) verwenden,
• verarbeitete Events in der DB speichern,
• die Webhook-Signatur und die Payload-Version prüfen,
• möglicherweise einen separaten Bulkhead/Breaker um den Handler legen.

Wie das im GiftGenius-Kontext aussieht

Für GiftGenius, das über Webhooks in ACP/Stripe integriert ist, ist Schutz vor Stürmen besonders in Peak-Saisons (Neujahr, Black Friday) wichtig. Dann gibt es viele Events:

• Erstellung von Intents,
• Zahlungsbestätigungen,
• Stornierungen,
• Rückerstattungen.

Wenn Ihr Handler „länger wird“ (z. B. durch Aufrufe externer APIs), riskieren Sie:

• dass ACP mit Retries beginnt,
• dass Events in Batches eintreffen,
• dass die Bestell-DB und der Worker-Pool voll laufen.

Das Muster „queue first“ + Idempotenz + Rate Limiting am Eingang dient genau als Versicherung gegen solche Szenarien.

6. Wie diese Muster zusammenwirken

Fassen wir alle Muster in einem Szenario zusammen und betrachten, wie sie im realen Flow „Empfiehl ein Geschenk und führe sofort den Checkout aus“ zusammenarbeiten.

Betrachten wir die Kette „ChatGPT → Gateway → Gift Service → Commerce → Webhooks“ am Beispiel eines Szenarios:

Der Nutzer sagt im Chat: „Empfiehl ein Geschenk und führe direkt den Checkout aus“.

1. Das Modell entscheidet, Ihr Tool suggest_and_checkout aufzurufen.
2. Das Gateway ruft den Gift-Service via fetchWithTimeout und den Bulkhead des Gift-Services auf.
3. Wenn der Gift-Service hängt, greift das Timeout; der Breaker um ihn herum wechselt nach einigen Fehlern in open, und folgende Anfragen bekommen sofort den MCP-Fehler „gift_service_unavailable“.
4. Wenn der Gift-Service antwortet, ruft das Gateway den Commerce-Service auf (wieder mit Timeout und separatem Bulkhead).
5. Alle Probleme mit Commerce lösen einen separaten Circuit Breaker aus, der strenger konfiguriert ist als beim Gift-Service (weil der Checkout kritisch ist).
6. Eine erfolgreiche Bestellung führt zu einem Webhook von ACP an Ihren /api/commerce/webhook, der das Event in eine Queue legt und schnell antwortet; Hintergrund-Worker verarbeiten die Zahlung, und wiederholte Webhooks mit derselben eventId werden als Duplikate ignoriert.

Am Ende:

• Ein hängender Empfehlungsservice legt den Checkout nicht lahm.
• Ein hängender Commerce verwandelt tool-calls nicht in minutenlange Spinner – ChatGPT erhält schnell einen sinnvollen Fehler.
• Webhook-Stürme brechen Ihren primären HTTP-Pfad nicht.
• Sie steuern die Degradationspunkte: Lieber personalisierte Empfehlungen temporär abschalten als Zahlungen lahmlegen.

7. Kleiner praktischer Checklisten-Abschnitt für Ihre App (erzählerisch)

Zusammengefasst lohnt es sich, in einer typischen ChatGPT App mit MCP/Gateway die folgenden Fragen der Reihe nach durchzugehen.

Zuerst prüfen Sie, ob es Timeouts für alle externen Aufrufe gibt. Der gesamte fetch-Code, DB- und LLM-Anfragen sollten einen Wrapper wie fetchWithTimeout mit angemessenen Werten nutzen. Wichtig ist, dass es keine Stellen gibt, an denen eine Anfrage unendlich hängen kann.

Als Nächstes identifizieren Sie die fragilsten Abhängigkeiten. Typischerweise sind das Zahlungsanbieter, ACP, große externe APIs und manchmal Ihre eigene Bestell-DB. Rund um sie sollten Sie einen Circuit Breaker hinzufügen, um sich vor einer Lawine an Wiederholungen in einen offensichtlich toten Service zu schützen. Gleichzeitig definieren Sie, wie sich ChatGPT verhalten soll, wenn der Breaker im Zustand open ist.

Danach betrachten Sie Ihre Ressourcen als „Schotten“. Läuft alles durch einen Connection Pool und einen Worker-Pool, oder haben kritische Operationen (Login, Checkout) ihre eigenen Parallelitätsgrenzen, unabhängig vom Empfehlungs- und Analytics-Service? Falls nicht, fügen Sie eine einfache Bulkhead-Implementierung hinzu – zumindest als grobes Limit paralleler Tasks.

Schließlich auditieren Sie alle eingehenden Webhooks. Prüfen Sie, ob sie einen Idempotency Key oder eine eventId haben, ob Sie nicht versuchen, schwere Arbeit synchron im HTTP-Handler zu erledigen, und ob Sie eine Welle von Retries überstehen, wenn Ihr Downstream temporär ausfällt. Falls nicht, verlagern Sie die Logik in eine Queue und Hintergrund-Worker.

Diese Abfolge bringt bereits ohne hochkomplexe Infrastruktur einen deutlichen Resilienzgewinn.

8. Typische Fehler im Umgang mit Timeouts, Circuit Breakers, Bulkheads und Webhook-Stürmen

Fehler Nr. 1: fehlende Timeouts „ganz unten“.
Entwickler setzen oft nur auf dem Gateway oder nur im Frontend Timeouts und vergessen, dass es im Backend noch DB, externe APIs und LLM gibt. Am Ende hat die äußere Anfrage scheinbar ein Timeout von 5 Sekunden, aber intern kann ein DB- oder Zahlungsaufruf minutenlang hängen, den Verbindungspool blockieren und Kaskadenausfälle auslösen.

Fehler Nr. 2: riesige Timeouts „für alle Fälle“.
Manchmal setzt man Timeouts von 60–120 Sekunden: „soll es doch durchlaufen“. Im ChatGPT-Kontext ist das fast immer schlecht. Der Nutzer springt ab, das Modell fängt an zu halluzinieren, und Ihre Ressourcen sind die ganze Zeit blockiert. Viel besser ist ein ehrlicher Abbruch nach 5–10 Sekunden mit einer verständlichen Beschreibung.

Fehler Nr. 3: Circuit Breaker ohne durchdachtes UX.
Manchmal wird ein Breaker „pro forma“ hinzugefügt, aber bei seiner Auslösung bekommt der Nutzer oder das Modell einen unverständlichen 500, „ECONNREFUSED“ oder „axios error“. Das GPT kann nicht sinnvoll erklären, was passiert, und beginnt zu fabulieren. Planen Sie die Fehlermeldungen so, dass sie für Menschen und das Modell verständlich sind.

Fehler Nr. 4: Ressourcenmischung ohne Bulkhead-Ansatz.
Klassisches Szenario: Ein Empfehlungs- (oder Analytics-) Service wird langsam, frisst den gesamten DB- oder Thread-/Worker-Pool, und danach sterben Checkout und Login gleich mit. Der Grund: Ressourcen sind nicht getrennt. Ohne irgendeine Bulkhead-Strategie kann ein zweitrangiges Feature die ganze Produktion lahmlegen.

Fehler Nr. 5: Webhooks wie normale Requests behandeln.
Einsteiger schreiben den Webhook-Handler oft wie einen normalen Controller: lange Business-Logik, Aufrufe zu Fremd-APIs, keine Idempotenz. Mit Retries und Duplikaten führt das zu doppelter Eventverarbeitung, komischen Bestellzuständen und Lastabstürzen im Sturm.

Fehler Nr. 6: Ignorieren der Idempotenz in Commerce-Szenarien.
Besonders gefährlich ist, wenn ein Zahlungswebhook eine Bestellung erneut anlegen oder ihren Zustand wiederholt ändern kann. Ohne Idempotency Key und Statusspeicherung der Eventverarbeitung bekommen Sie früher oder später doppelte Abbuchungen oder merkwürdige Bestellduplikate.

Fehler Nr. 7: der Versuch, alles mit setTimeouts und „magischen Delays“ zu reparieren.
Man versucht manchmal, Race Conditions und Sturmprobleme mit „warte 100 ms und es passt“ zu umgehen. In der Praxis macht das das Verhalten noch instabiler und schützt nicht vor echten Ausfällen. Der richtige Weg sind explizite Timeouts, Circuit Breaker, Queues und Idempotenz – nicht Schamanismus mit Verzögerungen.

Fehler Nr. 8: fehlende Priorisierung kritischer Pfade.
Wenn Checkout und Login unter denselben Limits laufen wie Analytics oder Empfehlungslogik, kann jede Überlastung Kritisches und Nebensächliches gleichermaßen umhauen. In einem resilienten Design sind Checkout und Auth „heilige Kühe“: separate Ressourcen, separate Limits, separate Alerts und SLOs.