Устойчивость системы: timeouts, circuit breakers, bulkheads, защита от штормов вебхуков

1. Зачем вообще думать про «устойчивость» в ChatGPT App

В обычном веб-приложении пользователь хотя бы видит URL, спиннер браузера, может обновить страницу. В ChatGPT пользователь видит один экран: чат и ваш App. Если что-то тормозит, он не различает, кто виноват — OpenAI, ваш Gateway, платёжка или соседский микросервис аналитики. Для него всё это «ChatGPT + ваш App».

Когда tool-call висит 30–60 секунд, модель ждёт, ждёт… и в лучшем случае извиняется за задержку. В худшем — галлюцинирует ответ вместо данных от вашего бэкенда. Поэтому устойчивость — это не только про SRE и uptime, это ещё и про качество ответа, тон поведения модели и метрики в Store.

В экосистеме ChatGPT App у нас несколько независимых контуров:

• ChatGPT ↔ MCP Gateway.
• Gateway ↔ ваши backend-/REST-сервисы (Gift REST API, Commerce REST API, Analytics Service и т.п.).
• Ваши сервисы ↔ внешние API (LLM, платежи, каталоги).
• Входящие вебхуки (ACP, Stripe, любые интеграции) ↔ ваши обработчики.

Проблема в том, что сбой в одном месте может вызвать каскад: Gateway честно ждёт зависший сервис, воркеры забиваются, соединения кончаются, клиенты начинают ретраить, и через пару минут у вас классическая «система БЭЛЬ»: всё горит и тонет одновременно. Именно от этого нас защищают четыре паттерна, про которые мы говорим сегодня:

• Timeouts — мы никогда не ждём вечно.
• Circuit breaker — мы не бьёмся в закрытую дверь.
• Bulkheads — мы строим «отсеки» и не даём утонуть всему кораблю.
• Защита от штормов вебхуков — мы признаём, что вебхуки приходят с дублями, всплесками и ретраями, и готовимся.

2. Timeouts: мы не ждём вечно

Что такое timeout и почему без него всё плохо

Timeout — это максимальное время, которое ваш код готов ждать ответа от зависимости: базы, MCP-сервера, внешнего HTTP API, модели. Если ответ не пришёл за заданное время — считаем вызов неуспешным, освобождаем ресурсы и возвращаем понятную ошибку или fallback.

Без таймаутов запросы могут:

• вечно висеть в ожидании,
• занимать соединения и пул потоков,
• блокировать последующие запросы,
• вызывать каскадные отказы.

Паттерн простой: «лучше предсказуемый отказ через 3–5 секунд, чем непонятная тишина 5 минут».

Важно помнить, что у нас есть таймауты на нескольких уровнях:

• на уровне прокси/балансировщика (Cloudflare, Nginx),
• на уровне MCP Gateway (HTTP-клиенты к микросервисам),
• в самих сервисах (вызовы к БД, внешним API, LLM).

Для ChatGPT в целом разумно стремиться к полному времени tool-call в диапазоне 5–10 секунд для обычных операций и максимум 20–30 секунд для особо тяжёлых. Всё, что дольше — почти гарантированный плохой UX.

Простой fetchWithTimeout в TypeScript

Начнём с практики. В GiftGenius MCP Gateway у нас есть вспомогательный HTTP-клиент, который ходит в gift-подборщик, в commerce-сервис, в аналитику. Обернём стандартный fetch в функцию с таймаутом:

// 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);
  }
}

Теперь в коде Gateway мы никогда не делаем «голый» fetch, только через этот 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();
}

Такой подход гарантирует, что даже если gift-сервис зависнет, через 4 секунды мы оборвём соединение и сможем отдать MCP-ошибку ChatGPT, а не держать соединение до упора.

Где именно ставить таймауты в GiftGenius

В нашем примере GiftGenius:

• На уровне Gateway: таймауты на вызовы Gift REST API, Commerce REST API, Analytics Service / REST API.
• Внутри этих сервисов: таймауты на вызовы к БД, ACP/платёжкам, внешним рекомендательным API.
• На входе в Gateway: общий таймаут запроса от ChatGPT, чтобы tool-call не превращался в «вечный спиннер».

Важно, чтобы время ожидания на верхнем уровне было чуть больше, чем на внутренних. Например, если Gateway ждёт backend 5 секунд, а backend ждёт БД 3 секунды, то у нас есть запас на обработку и сериализацию результата.

Как объяснять таймауты ChatGPT модели

Для ChatGPT важно возвращать семантические ошибки, а не молчаливо ронять соединения. Вместо абстрактного 500 лучше вернуть структурную MCP-ошибку, которую модель сможет озвучить пользователю: «Сервис подбора подарков сейчас перегружен, попробуй ещё раз чуть позже» и так далее.

Это значит, что в Gateway при таймауте надо:

1. Поймать AbortError или наш timeout_….
2. Сформировать MCP-ответ с осмысленным кодом и коротким описанием.
3. Дать модели возможность решить, как объяснить это человеку.

Таймауты решают проблему зависших запросов, но если зависимость начала массово падать, они не спасают от лавины одинаковых неудачных попыток. Здесь нам нужен следующий уровень защиты — circuit breaker.

3. Circuit breaker: «автомат» против умирающих сервисов

Интуиция: почему одного таймаута мало

Мы уже научились ограничивать время ожидания отдельных вызовов с помощью таймаутов. Таймаут защищает один конкретный вызов. Но если зависимость умерла «плотно» (например, commerce-сервис падает по OOM (Out Of Memory) при каждом запросе), мы продолжим к ней ходить, каждый раз ждать 3–5 секунд, ловить ошибку, загружать сеть и CPU и снова ждать.

Circuit breaker (автомат) добавляет память: он отслеживает ошибки и таймауты и, когда их становится слишком много, перестаёт вообще отправлять запросы в этот сервис. Вместо этого он сразу возвращает быстрый отказ или fallback. Через некоторое время он осторожно пробует снова в режиме half-open.

Классическое состояние автомата:

• Closed — всё нормально, запросы ходят.
• Open — сервис считается «мертвым», запросы не ходят, сразу ошибка.
• Half-open — пробуем ограниченное количество запросов; если успешны — возвращаемся в closed, если снова упали — опять open.

Простая схема circuit breaker

Небольшая диаграмма:

stateDiagram-v2
    [*] --> Closed
    Closed --> Open: слишком много ошибок
    Open --> HalfOpen: истёк cooldown
    HalfOpen --> Closed: несколько успехов подряд
    HalfOpen --> Open: снова ошибки
    Open --> Open: быстрый отказ

Мини-реализация circuit breaker в TypeScript

В продакшене обычно используют готовые библиотеки (для Node.js есть, например, opossum или лёгкие self-made решения), но чтобы понять механику, достаточно компактного класса.

Пример крайне упрощённого breaker’а вокруг вызова commerce-модуля:

// 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;
        }
    }
}

И использование в клиенте commerce-сервиса:

// 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();
    });
}

Здесь, когда commerce начинает массово отвечать ошибками или не успевать до таймаута, после нескольких неудач breaker переходит в open. В этом состоянии в течение cooldownMs мы вообще не пытаемся ходить в сервис и сразу возвращаем ошибку circuit_open.

Что видеть из ChatGPT, когда breaker «отрубил» сервис

С точки зрения ChatGPT лучше, если вы:

• Быстро отвечаете MCP-ошибкой «commerce_unavailable» или «gift_service_overloaded».
• Добавляете понятное описание: «Сервис оплаты временно недоступен, давай попробуем позже».
• Не скрываете ошибку за бесконечными ретраями.

Это как раз тот случай, когда «быстрый, честный отказ» лучше, чем долгое подвисание. Особенно в чек-ауте: пользователь скорее переживёт честное сообщение, чем будет 40 секунд смотреть на спиннер и получит «что-то пошло не так».

Таймауты и breaker защищают нас от «плохих» или лежащих зависимостей, но они не решают проблему, когда один тип нагрузки съедает все ресурсы и начинает душить остальные части системы. Для этого нужен ещё один слой — bulkheads.

4. Bulkheads: изоляция «отсеков», чтобы один не утопил весь корабль

Аналогия с кораблём

Паттерн bulkhead назван в честь переборок в корабле: если в одном отсеке пробоина, вода не растечётся по всему кораблю. В архитектуре это значит: разделить ресурсы между разными направлениями работы, чтобы один перегруженный сервис не съел всё — CPU, соединения, пулы — и не положил критические пути.

В микросервисах это обычно делается через отдельные:

• пулы HTTP-соединений,
• пулы потоков/воркеров,
• очереди/топики,
• даже отдельные БД-кластеры для критически важных операций.

Идея в том, что если сервис рекомендаций подарков начинает работать медленнее и заедать, он исчерпает только свои ресурсы, но не сломает checkout и авторизацию.

Bulkheads в мире Node.js и MCP Gateway

В Node.js у нас нет потоков в классическом смысле (есть event loop и воркеры), но мы можем ограничивать количество параллельных задач для каждого направления.

Пример: в Gateway есть три внешних зависимости:

• Gift-сервис (подбор подарков, тяжёлые LLM-вызовы).
• Commerce-сервис (чек-аут, ACP).
• Analytics-сервис (логирование событий).

Мы можем ввести простые лимиты на одновременные запросы к каждому из них.

Например, небольшой «семафор» для ограничения параллельности:

// 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();
        }
    }
}

И использование для сервисов:

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

const giftBulkhead = new Bulkhead(10);      // до 10 параллельных
const commerceBulkhead = new Bulkhead(3);   // чек-аут сильно ограничен
const analyticsBulkhead = new Bulkhead(50); // можно много

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

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

Таким образом, даже если GPT решит массово спросить «сделай мне 30 сложных подборок подарков», они будут выполняться максимум по 10 одновременно, а чек-аут сможет продолжать работать, используя свой отдельный лимит.

GiftGenius: какие отсеки мы хотим

В GiftGenius разумно сделать отдельные отсеки для:

• Подбора подарков (LLM-тяжёлые, менее критичны, можно замедлить).
• Checkout/ACP (супер-критично, надо защищать по максимуму).
• Аналитики/логов (важно, но можно немного потерпеть задержки).

В более продвинутой архитектуре вы ещё и деплоите их как разные кластеры с отдельными ресурсами, но в пределах этой лекции нам важна именно идея: не давать второстепенным фичам «съесть» весь кислород.

Все три этих паттерна — таймауты, circuit breaker и bulkheads — относятся к тому, как вы ходите наружу, к своим зависимостям. Но есть ещё один класс угроз устойчивости: входящие потоки событий, которые могут завалить вас даже при идеально настроенных исходящих вызовах. Самый типичный пример — вебхук-штормы.

5. Вебхук-штормы: когда мир шлёт вам события чаще, чем вы готовы

Как ведут себя вебхуки в реальности

Четвёртый источник проблем с устойчивостью — входящие события: вебхуки от ACP, Stripe и других систем. Именно они могут устроить настоящий «шторм», даже если у вас уже настроены таймауты, circuit breaker’ы и bulkhead’ы.

Вебхуки — это не HTTP-запрос «по запросу», а «push»-события от внешних систем (Stripe, ACP, внешние магазины и т. д.). У них есть несколько неприятных свойств:

• Доставка минимум один раз (at-least-once) — значит, дубликаты неизбежны.
• Порядок доставки не гарантирован.
• При ошибках они любят ретраить: сначала через секунду, потом через 10, потом через минуту… пока вы не ответите 2xx.
• В пике (например, на распродаже) они приходят пачками, создавая «шторм».

Если ваш обработчик не идемпотентен и работает слишком долго, он становится бутылочным горлышком, вся очередь забивается, а ретраи только усиливают шторм. В результате вы можете положить базу, очередь, воркер-пулы — и по цепочке остальную систему.

Базовые принципы защиты от штормов

Есть несколько идей, которые сильно повышают шансы выжить при шторме:

Во-первых, queue-first, process-later. В идеале входящий вебхук не должен синхронно выполнять тяжёлую работу. Вместо этого он как можно быстрее валидирует подпись/формат, кладёт задачу в очередь и отвечает 200 OK. Обработка идёт асинхронно в воркере. Если вам нужно «быстрое подтверждение» для ChatGPT, вы можете держать отдельный контур нотификаций.

Во-вторых, идемпотентность обработчика. Повторный вебхук по той же операции не должен «сделать заказ ещё раз» или «списать деньги дважды». Обычно это решается хранением idempotency key или eventId и проверкой, обрабатывали ли мы уже это событие.

В-третьих, rate limiting и circuit breaker на приёмнике. Даже если отправитель штормит, вы можете:

• ограничить RPS по IP/подписке/endpoint,
• временно отдавать 429 или 503, чтобы замедлить ретраи,
• использовать breaker, чтобы не лить поток в сломанный downstream (например, БД заказов).

Пример Next.js-обработчика вебхука в GiftGenius

Представим, что у нас есть ACP/платёжка, которая шлёт вебхук о статусе заказа в POST /api/commerce/webhook. Мы хотим:

• быстро принять событие и положить его в очередь,
• не обрабатывать его синхронно,
• не сломаться от дублей.

Упрощённый пример (без проверки подписи и реальной очереди — это будет в модулях про безопасность и очереди):

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

// Здесь у нас могла бы быть Redis/кью, пока имитируем массив
const inMemoryQueue: any[] = [];
const processedEvents = new Set<string>(); // идемпотентность (для демо)

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 });
    }

    // В реальности здесь будет проверка подписи и схемы

    inMemoryQueue.push(event); // кладём в очередь для фоновой обработки
    // Фоновый воркер позже обработает и пометит ID как обработанный
    return NextResponse.json({ ok: true });
}

Пока это псевдо-реализация, но важны два момента:

1. Синхронная часть максимально лёгкая.
2. Мы закладываем идемпотентность вокруг event.id.

В реальной жизни вы будете:

• использовать внешнюю очередь (SQS, RabbitMQ, Kafka),
• хранить обработанные события в БД,
• проверять сигнатуру вебхука и версию payload’а,
• возможно, применять отдельный Bulkhead/Breaker вокруг обработчика.

Как это выглядит в контексте GiftGenius

Для GiftGenius, интегрированного с ACP/Stripe через вебхуки, защищённость от штормов особенно важна в пиковые сезоны (Новый год, Черная пятница). Там много событий:

• создание intent’ов,
• подтверждение платежей,
• отмены,
• возвраты.

Если ваш обработчик начнёт «удлиняться» (например, из-за запросов к внешнему API), вы рискуете тем, что:

• ACP начнёт ретраить,
• события придут пачками,
• БД заказов и воркер-пул будут забиты.

Паттерн «queue first» + идемпотентность + rate limiting на входе как раз и служит страховкой от таких сценариев.

6. Как эти паттерны работают вместе

Теперь соберём все эти паттерны в один сценарий и посмотрим, как они работают в реальном флоу «Подбери подарок и сразу оформи заказ».

Рассмотрим цепочку «ChatGPT → Gateway → Gift Service → Commerce → вебхуки» на примере сценария:

Пользователь в чате говорит: «Подбери подарок и сразу оформи заказ».

1. Модель решает вызвать ваш tool suggest_and_checkout.
2. Gateway вызывает gift-сервис через fetchWithTimeout и bulkhead gift-сервиса.
3. Если gift-сервис завис — срабатывает таймаут; breaker вокруг него через некоторое количество ошибок перейдёт в open, и следующие запросы будут сразу получать MCP-ошибку «gift_service_unavailable».
4. Если gift-сервис отвечает, Gateway вызывает commerce-сервис (опять с таймаутом и отдельным bulkhead).
5. Любые проблемы с commerce вызывают отдельный circuit breaker, настроенный строгее, чем у gift (потому что checkout критичен).
6. Успешный заказ приводит к вебхуку от ACP в ваш /api/commerce/webhook, который кладёт событие в очередь и отвечает быстро; фоновые воркеры обрабатывают оплату, а повторные вебхуки по тому же eventId игнорируются как дубликаты.

В итоге:

• Виснущий сервис подбора не кладёт checkout.
• Виснущий commerce не превращает все tool-calls в минутный спиннер — ChatGPT быстро получает осмысленную ошибку.
• Шторма вебхуков не ломают ваш основной HTTP-контур.
• Вы контролируете места деградации: лучше временно отключить персонализированные рекомендации, чем валить оплату.

7. Небольшой практический чек-лист для вашего App (в повествовательной форме)

Если обобщить, в типичном ChatGPT App с MCP/Gateway имеет смысл последовательно пройтись по следующим вопросам.

Сначала вы проверяете, есть ли таймауты на всех внешних вызовах. Весь код fetch, запросы к БД и к LLM должен использовать обёртку вроде fetchWithTimeout с адекватными значениями. Важно, чтобы не было мест, где запрос может висеть бесконечно.

Дальше вы определяете наиболее хрупкие зависимости. Как правило, это платёжки, ACP, крупные внешние API и иногда ваша же БД заказов. Вокруг них имеет смысл добавить circuit breaker, чтобы защититься от лавины повторений в заведомо мёртвый сервис. При этом вы сразу решаете, как ChatGPT будет вести себя, когда breaker в состоянии open.

После этого вы смотрите на свои ресурсы как на «отсеки». Всё ли у вас идёт через один connection pool и один воркер-пул, или критические операции (логин, checkout) имеют свои ограничения параллельности, независимые от сервиса рекомендаций и аналитики. Если нет — добавляете простейшую реализацию bulkhead’ов, хотя бы как грязный лимит параллельных задач.

Наконец, вы проводите аудит всех входящих вебхуков. Проверяете, есть ли в них idempotency key или eventId, не пытаетесь ли вы делать тяжёлую работу синхронно в HTTP-обработчике и умеете ли вы пережить волну ретраев, если ваш downstream временно упадёт. Если нет — переносите логику в очередь и фоновые воркеры.

Такая последовательность шагов даёт очень приличный прирост устойчивости даже без супер-сложной инфраструктуры.

8. Типичные ошибки при работе с timeouts, circuit breakers, bulkheads и вебхук-штормами

Ошибка №1: отсутствие таймаутов «где-то внизу».
Разработчики часто ставят таймаут только на Gateway или только на фронтенд, забывая, что внутри backend’а есть ещё БД, внешние API и LLM. В итоге внешний запрос вроде бы имеет таймаут 5 секунд, но внутри один вызов к БД или платёжке может висеть минутами, блокируя пул соединений и вызывая каскадные отказы.

Ошибка №2: гигантские таймауты «на всякий случай».
Иногда ставят таймаут 60–120 секунд: «пусть уж дотянет». В ChatGPT-контексте это почти всегда плохо. Пользователь уходит, модель начинает галлюцинировать, а ваши ресурсы всё это время заблокированы. Гораздо лучше честный отказ через 5–10 секунд с понятным описанием.

Ошибка №3: circuit breaker без продуманного UX.
Иногда breaker добавляют «для галочки», но при его срабатывании пользователю или модели прилетает непонятный 500, «ECONNREFUSED» или «axios error». В итоге GPT не может адекватно объяснить, что происходит, и начинает выдумывать. Стоит сразу продумывать формулировки ошибок, которые будут понятны и людям, и модели.

Ошибка №4: смешивание ресурсов без bulkhead-подхода.
Классический сценарий: один сервис рекомендаций (или аналитики) начинает тормозить, съедает весь пул соединений к БД или thread-pool, и вслед за ним умирают чек-аут и логин. Всё потому, что ресурсы не разделены. Отсутствие хоть какого-то bulkhead-подхода приводит к тому, что второстепенная фича может положить весь прод.

Ошибка №5: обработка вебхуков как обычных запросов.
Новички часто пишут вебхук-обработчик так же, как обычный контроллер: длинная бизнес-логика, запросы к сторонним API, отсутствие идемпотентности. В условиях ретраев и дублей это приводит к двойной обработке событий, странным состояниям заказов и падениям по нагрузке при шторме.

Ошибка №6: игнорирование идемпотентности в commerce-сценариях.
Особенно опасно, когда вебхук оплаты может создать заказ ещё раз или повторно изменить его состояние. Без проверки idempotency key и хранения статуса обработки события вы рано или поздно получите двойное списание или странные дубликаты заказов.

Ошибка №7: попытка чинить всё setTimeout-ами и «магическими задержками».
Иногда хотят обойти race condition и проблемы шторма через «подождать 100 мс и будет нормально». На практике это делает поведение ещё более нестабильным и ничуть не защищает от реальных сбоев. Правильный путь — явные таймауты, circuit breaker, очереди и идемпотентность, а не шаманство с задержками.

Ошибка №8: отсутствие приоритизации критических путей.
Когда checkout и логин живут в тех же лимитах, что и аналитика или рекомендательная логика, любая перегрузка может одинаково положить и критические, и второстепенные части. В устойчивом дизайне checkout и auth — «священные коровы»: для них отдельные ресурсы, отдельные лимиты, отдельные алерты и SLO.