Bulkhead Pattern
The Bulkhead pattern isolates resources into separate pools so a failure or overload in one part of a system cannot starve the others. Like a ship's watertight compartments, it contains damage and keeps the rest of the system running.
Best Practice: Bulkhead Pattern
The Bulkhead pattern takes its name from a ship's hull, which is divided into watertight compartments so a breach in one section does not sink the whole vessel. In software, it partitions resources such as thread pools, connection pools, or service instances so that a failure or surge in one area cannot starve the rest. If one downstream dependency becomes slow and saturates its dedicated pool, other workloads keep running because they draw from separate pools. Michael Nygard described this idea in Release It!, and Microsoft documents it as a cloud design pattern. It matters anywhere shared resources create a single point of contention.
Step-by-Step Implementation Guidance
- Identify shared resources that could be exhausted by one consumer: threads, connections, queues.
- Group consumers or dependencies by criticality and expected load.
- Allocate isolated resource pools per group rather than one shared pool.
- Set per-pool limits so one pool cannot borrow from another.
- Define behavior when a pool is full: reject fast, queue with a bound, or shed load.
- Combine with circuit breakers and timeouts for layered resilience.
- Monitor utilization per pool to tune allocations.
Common Mistakes Teams Make When Ignoring This Practice
- Sharing one global thread pool, so one slow dependency starves everything.
- Allocating pools without limits, defeating the isolation.
- Sizing pools by guesswork instead of measured load.
- Forgetting to define overflow behavior, causing silent queue buildup.
- Treating bulkheads as a substitute for, rather than a complement to, circuit breakers.
Tools and Techniques That Support This Practice
- Resilience4j bulkhead module for Java.
- Polly bulkhead isolation for .NET.
- Kubernetes resource requests and limits for pod-level isolation.
- Dedicated connection pools per dependency.
How This Practice Applies to Different Migration Types
- Cloud Migration: Isolate calls to legacy on-premise systems so their latency cannot drain cloud-side capacity.
- Database Migration: Give the new datastore its own connection pool so issues stay contained.
- SaaS Migration: Dedicate a pool to each external SaaS so one slow vendor does not affect others.
- Codebase Migration: Isolate newly extracted services behind their own pools during stabilization.
Checklist
- Identify shared, exhaustible resources.
- Group consumers by criticality and load.
- Allocate isolated pools per group.
- Enforce hard per-pool limits.
- Define overflow and load-shedding behavior.
- Combine with circuit breakers and timeouts.
- Monitor per-pool utilization and tune.