Named after the watertight compartments in ship hulls, the bulkhead pattern isolates resources so that a failure in one part of your system can't drown the rest. If one compartment floods, the others stay dry and the ship stays afloat.

The classic failure mode it prevents: resource exhaustion cascades. Your service calls three downstream APIs from a shared thread pool of 100 threads. One downstream (say, the recommendations API) starts responding in 30 seconds instead of 100ms. Within minutes, all 100 threads are blocked waiting on recommendations. Now checkout and auth calls — which were perfectly healthy — have no threads available. Your entire service is down because one non-critical dependency got slow.

The fix: give each downstream its own isolated resource pool.

• Thread pool bulkheads: separate executor pools per dependency. Recommendations gets 20 threads, checkout gets 50, auth gets 30. If recommendations saturates, checkout is unaffected.
• Connection pool bulkheads: separate DB connection pools for read-heavy analytics queries vs. transactional writes, so a runaway report doesn't starve your order pipeline.
• Process/container bulkheads: run critical and non-critical workloads in separate pods so a memory leak in one doesn't OOM-kill the other.
• Tenant bulkheads: in multi-tenant systems, cap per-tenant resource usage so one noisy customer can't degrade everyone else.

Real-world example: Netflix's Hystrix (and its successor, resilience4j) built bulkheads as a first-class concept. Each downstream call goes through a named bulkhead with a configured concurrency limit. When the limit is hit, new requests fail fast instead of queueing — which preserves capacity for healthy dependencies.

Sizing rule of thumb: use Little's Law. threads = throughput × latency. If a dependency handles 50 req/s with p99 latency of 200ms, you need 50 × 0.2 = 10 threads steady-state. Add ~50% headroom for spikes → allocate ~15 threads. Set the bulkhead limit there, not at "whatever's convenient."

The tradeoff to accept: bulkheads reduce peak throughput per dependency. A shared pool of 100 threads can burst all 100 to recommendations during a spike; a 20-thread bulkhead cannot. You're trading peak capacity for blast-radius containment. For anything user-facing, that trade is almost always worth it.

Pair bulkheads with circuit breakers and timeouts. Bulkhead caps how many concurrent calls; timeout caps how long each waits; circuit breaker stops trying when the dependency is clearly broken. Together they form the resilience trifecta.