Перейти к содержанию

Circuit Breaker, Bulkhead и Timeouts

Раздел 04 · Типы достоверности

Тип материала: инженерный разбор. Схемы и примеры иллюстративные. Рекомендации — INFERENCE; учебные параметры — HYPOTHETICAL.

Проверка источников: 2026-11-02. Версии и границы первоисточников перечислены в конце. Documented contracts не означают выполненный runtime test.

Принцип работы и границы

Timeout ограничивает ожидание caller; он не доказывает остановку remote операции. Circuit breaker временно не допускает новые calls к зависимому сервису после классифицированных failures. Bulkhead выделяет отдельные ресурсы для изолируемых потоков работы. Эти механизмы защищают capacity, но не восстанавливают данные сами.

Модель closed/open/half-open описана в оригинальном Circuit Breaker. INFERENCE: breaker должен учитывать отдельный dependency/tenant scope, ограничивать probes и считать failure types: validation error клиента не означает outage провайдера.

Общий request deadline распределяется между queue, connection setup и execution. На ingress храните operation_id до remote call, а unknown результат передавайте reconciliation workflow. Отмена future не является compensation уже проведённого платежа.

Иллюстративная архитектура

flowchart LR
 R[Request deadline] --> B[Bulkhead capacity]
 B --> C{Circuit state}
 C -->|closed or limited probe| D[Dependency]
 C -->|open| F[Explicit pending or rejection]
 D --> U[Resolve ambiguous outcome]

Failure scenarios

Сбой одного PSP заполняет общий connection pool и блокирует здоровый PSP. Одновременный half-open всех instances вызывает новый overload. Fallback возвращает stale balance как подтверждение доступности средств. Timeout response скрывает успешно committed debit.

Recovery protocol

  1. Изолировать pools/queues проблемной зависимости и остановить новые небезопасные mutations.
  2. Сохранить uncertain operations и проверить status через независимый recovery path.
  3. Выпустить ограниченные half-open probes, не весь накопленный backlog.
  4. Разгрузить очередь с per-tenant fairness и retry budget.
  5. Проверить error rate вместе с rejected/pending counts: открытый breaker искусственно уменьшает remote failures.

Trade-offs и критерии выбора

Отдельные pools увеличивают reserved capacity и конфигурацию. Общий breaker может наказывать здоровые tenants; слишком мелкий scope делает статистику нестабильной. Fail-open допустим лишь когда policy принимает последствия, например необязательное enrichment, но не bypass ledger authorization.

FinTech и iGaming

При outage external KYC сервису можно оставить заявку pending; автоматически одобрять её из-за breaker нельзя без отдельной policy. Betting price lookup можно отвергнуть при устаревшей версии, не подменять свежие odds кешем молча.

Практический пример

Учебное упражнение: два downstream routes, один зависает. Зафиксируйте, что здоровый route сохраняет доступные worker slots, число probes ограничено, а timed-out command остаётся unresolved до lookup. См. timeout/retry. Параметры теста не являются SLA.

Типичные ошибки проектирования

Единый pool для critical и batch; fallback success без business evidence; breaker без лимита probe concurrency; timeout короче нормального queueing и отсутствие отмены server work.

Вопросы на собеседовании

Breaker заменяет timeout? Нет: без deadline первые hanging calls могут занять все ресурсы ещё до открытия breaker.

Bulkhead гарантирует correctness? Он ограничивает распространение resource failure; бизнес-инвариант требует транзакций и identity.

Дополнительные источники