Pattern 3: The Bulkhead

Quarantine the Failure

The name Bulkhead comes from ship design. A ship's hull is divided into watertight compartments. If one compartment floods, the watertight doors prevent the flood from spreading to adjacent compartments. The ship stays afloat even with a breach.

In software, a bulkhead isolates resource pools so that a failure in one area cannot consume resources needed by another area.

The Thread Pool Exhaustion Problem

Consider a web application that handles two types of requests:

1. Critical: User authentication (login, session validation)
2. Non-Critical: Fetching product recommendations from a slow third-party API

Your web server has a thread pool of 50 threads. Each incoming request occupies one thread until it completes.

Now the Recommendation API starts hanging — every request takes 60 seconds before timing out. Here is what happens:

• Request 1 (recommendations): Thread 1 occupied, waiting.
• Request 2 (recommendations): Thread 2 occupied, waiting.
• ...
• Request 50 (recommendations): Thread 50 occupied, waiting.
• Request 51 (login attempt): No threads available. 503 Service Unavailable.

A non-critical feature — product recommendations — has taken down your authentication system. Users cannot log in. This is a cascading failure: one dependency's slowness propagates to unrelated functionality.

The Bulkhead Solution

Partition your resource pools by workload type:

Now when the Recommendation API hangs:
- The 10 threads in the Recommendation Pool fill up.
- Requests 11+ for recommendations are rejected immediately ("pool exhausted") with a fast error.
- The 40 threads in the Login Pool are completely unaffected.
- Users can still log in.

The failure is contained. It degrades one feature without cascading to others.

Bulkheads Beyond Thread Pools

Thread pools are the most common bulkhead implementation, but the pattern applies to any shared resource:

• Connection pools: Separate database connection pools for read-heavy analytics queries vs. write-heavy transactional operations.
• Memory: Separate heap allocations or container memory limits for different services.
• CPU: Kubernetes resource limits (requests and limits) act as bulkheads at the container level.
• Network bandwidth: Quality of Service (QoS) policies that prioritize critical traffic.

Key Point — Bulkheads Require Capacity Planning

Partitioning resources means you cannot use 100% of your capacity for any single workload. If you allocate 40 threads to Login and 10 to Recommendations, a sudden spike in login traffic cannot borrow the idle recommendation threads. This is the trade-off: isolation costs flexibility. Size your pools based on observed peak traffic per workload, with headroom. Monitor pool utilization and pool-exhaustion rejection rates as key metrics — a pool that is never exhausted may be over-allocated; one that is frequently exhausted needs more capacity or a faster upstream dependency.