Bulkhead pattern на собеседовании системного аналитика

Идея bulkhead

Из ship-building. Cabin (отсек) изолирует water flooding — другие cabins safe.

В software — изолировать resources between concurrent operations. Failure / overload одной не affects других.

Thread pool isolation

Different downstream services — different thread pools.

Service A:
  ├─ Pool for service B (10 threads)
  ├─ Pool for service C (10 threads)
  └─ Pool for service D (10 threads)

Если B slow → blocks B's pool. C, D's pools unaffected.

В Hystrix (deprecated), Resilience4j — built-in.

Pros: strong isolation.

Cons: memory cost (thread per pool).

Semaphore-based

Lighter alternative thread pools.

Service A:
  Semaphore (max 10 concurrent calls to B)
  
Limit concurrent calls без spawn threads. Когда reach limit — reject / queue.

Pros: less memory.

Cons: не isolate в случае blocking calls (caller's thread blocks).

Connection pools

Each downstream — separate connection pool.

DB pool:
  primary_db: 50 connections
  analytics_db: 20 connections
  
External API:
  payment_api: 10 connections
  notification_api: 30 connections

Saturation одного pool не drains others.

Applications

Microservices clients. Каждому downstream свой pool / semaphore.

HTTP servers. Tomcat / Jetty — separate pools для different endpoints.

DB clients. Separate pools для read / write replicas.

Background jobs. Different queues / worker pools per job type. Heavy job не blocks light tasks.

Связанные темы

• Circuit Breaker для SA
• API Gateway и BFF для SA
• Capacity planning для SA
• Service mesh для SA
• Подготовка к собесу системного аналитика

FAQ

Это официальная информация?

Нет. Статья основана на работах Michael Nygard «Release It!».

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.