Bulkhead Pattern

The Titanic had bulkheads. Watertight compartments designed so that if the hull breached in one section, the flooding stayed contained. The ship could survive four compartments flooding simultaneously. The iceberg breached five. The bulkheads failed not because the idea was wrong, but because the walls were not tall enough.

Software systems have the same problem. Your application calls three downstream services. They all share one thread pool of 200 threads. Service C gets slow. Threads pile up waiting on C. Now there are no threads left for services A and B, which are perfectly healthy. One slow dependency sinks the entire application. Not because A and B failed. Because they shared the same pool as C.

The bulkhead pattern in software is the same idea as on a ship: give each dependency its own isolated pool of resources. When one pool floods, the others stay dry. Netflix built this into Hystrix in 2012 after cascading failures in 2011 proved that a shared thread pool is a single point of failure even when the threads themselves are fine.

Bulkheads come in two forms, and the choice between them depends on your latency budget.

Netflix's rule from their Hystrix documentation: use thread pool bulkheads for any downstream call slower than 100 milliseconds, where the 1 ms overhead is negligible. Use semaphore bulkheads for faster calls where the context switch would be a meaningful percentage of total latency.

The critical difference is interrupt capability. A thread pool bulkhead can kill a stuck call by interrupting the thread. A semaphore bulkhead cannot, because the call runs on the caller's own thread. If a semaphore-guarded call hangs, that caller thread hangs with it. Thread pool bulkheads give you a hard timeout guarantee. Semaphore bulkheads give you a concurrency limit but no timeout enforcement.