Scalability
Bulkhead
Isolating resources — separate connection pools, thread pools or service instances per dependency — so a failure or overload in one area cannot consume everything and sink the whole system, like watertight compartments in a ship. It contains the blast radius. The cost is less resource sharing and more capacity to provision up front.
Purpose
The bulkhead pattern partitions resources — thread pools, connection pools, instance groups — so each dependency or workload draws from its own compartment, like a ship's watertight sections. When one dependency stalls, it exhausts only its own pool; the rest of the system sails on.
When to Use It
Isolating a slow third-party API so its hangs cannot consume every worker thread; separate connection pools per downstream service; dedicated instances for a noisy batch workload so it cannot starve interactive traffic; per-tenant quotas in multi-tenant systems.
Trade-offs
Partitioned resources cannot be shared, so total provisioning rises — ten pools of ten connections cannot lend to each other like one pool of a hundred can. Sizing per compartment takes thought; too small throttles a healthy dependency, too large defeats the isolation.
Implementation
Give each external dependency its own bounded pool with its own queue and timeout; reject fast when a compartment is full rather than queueing forever. At infrastructure level, separate node pools or autoscaling groups per workload class. Combine with circuit breakers — bulkheads contain the damage, breakers stop inflicting it.