resilience

Bulkhead Pattern

Isolate workloads into fixed-capacity compartments — prevent one overwhelmed resource from starving the rest

Active0/3
Queued0/4
Submitted0
Succeeded0
Errors0
Rejected0
Execution Slots (0/3)
empty
empty
empty
Queue (0/4)
·
·
·
·
queue empty

// configuration

PRESETS:

// event log

No events yet. Submit a task to begin.

// how it works

  • Named after watertight compartments in a ship's hull.
  • Limit concurrent executions with a fixed number of slots.
  • When slots are full, excess tasks wait in a bounded queue.
  • When both slots and queue are full, new tasks are rejected immediately.
  • When a running task finishes (success or error), the next queued task is promoted.
  • Failing tasks still release their slot — errors don't leak capacity.

// trade-offs

  • Prevents resource exhaustion from one misbehaving dependency
  • Provides back-pressure — callers learn immediately when capacity is full
  • Isolates workloads so failure in one partition doesn't cascade
  • Sizing slots & queue too small causes unnecessary rejections
  • Sizing too large defeats the purpose of isolation
  • Requires tuning per-service based on observed concurrency

// real-world usage

  • Hystrix / Resilience4j bulkhead (Java microservices)
  • Thread pool isolation per downstream dependency
  • Connection pool limits per database / service
  • Kubernetes resource quotas per namespace
  • Composition: bulkhead → timeout → retry → circuit-breaker