Bulkheads For Isolation
The bulkhead pattern borrows from ship design, where the hull is split into watertight compartments so a single breach floods only one section. In concurrent systems, bulkheads partition resources so one misbehaving component cannot drown the whole application.
The most common form gives each dependency its own thread pool or connection set. If the payments service hangs, only the payments pool fills up. Requests for search and catalog use separate pools and keep flowing. Without isolation, a shared pool means one slow dependency starves every feature at once.
Bulkheads can partition many resources:
- Thread pools One per critical downstream call.
- Connection pools Separate database or queue connections per workload.
- Semaphores Cap concurrent calls to each dependency, a lightweight alternative to whole pools.
The cost is some overhead and tuning, since each compartment must be sized. The benefit is fault isolation: failures are contained, and partial functionality survives. Bulkheads pair naturally with circuit breakers and timeouts. The breaker stops hammering a dead dependency, the timeout bounds each call, and the bulkhead ensures the blast radius stays inside one compartment.
Key idea
Bulkheads partition pools and semaphores per dependency so one overloaded component is contained instead of sinking the whole system.