Why Ships Don't Sink From One Hole
In 1912, the Titanic hit an iceberg that breached 5 of its 16 watertight compartments. The ship sank because the compartments weren't fully sealed at the top. Water spilled from one compartment into the next, flooding the entire hull. But the engineering principle was sound: divide the hull into isolated sections so that a breach in one section doesn't flood the entire ship.
Modern ships do this properly. A hole in compartment 3 fills compartment 3 with water. Compartments 1, 2, 4, 5 remain dry. The ship stays afloat.
In software, the equivalent of a "hole in the hull" is a dependency that goes slow or unresponsive. Without bulkheads, one slow API call can consume all your thread pool connections, blocking every other request in the system, even ones that don't touch the slow dependency. With bulkheads, the slow dependency gets its own limited pool of resources. When those resources are exhausted, only requests to that dependency are affected. Everything else continues normally.
Netflix learned this the hard way. Before Hystrix, a single slow downstream could exhaust the entire Tomcat thread pool (default: 200 threads). A recommendation database with 8-second response times would pin all 200 threads within 25 seconds. Search, checkout, user profiles, everything died because they all shared the same thread pool. Hystrix introduced bulkhead isolation: each downstream got its own thread pool. The recommendation database going slow could only fill its own 20-thread pool. The other 180 threads served search, checkout, and profiles normally.
Each cell is one worker. A filled cell means that worker is blocked, waiting on the dependency that stopped answering. Occupancy was sampled every 100 milliseconds while the run was happening, so this is what was actually there rather than what should have been.
On the left the sick dependency owns the whole pool. It takes a few seconds. Requests to it arrive faster than they finish, each one holds a worker for five seconds, and the pool is gone. Nothing is left for anything else. Requests to the perfectly healthy dependency then queue behind them, and the ones that finish take 8.5 seconds.
On the right the same sixteen workers are split down the middle. The sick side fills up exactly as before. The other eight cannot be taken, so the healthy path answers in 7.6 milliseconds and rejects nothing.
No capacity was added. Sixteen workers both times, same arrival rate, same failure. Only the accounting changed, and the healthy path went from 8.5 seconds to 7.6 milliseconds.
There is a cost, and it is real. The sick dependency finished 32 requests on the shared pool and 16 behind the wall. A bulkhead does not rescue the failing dependency. It gives up on it sooner and spends what it frees on everything else. That is the trade you are making, and it is usually the right one.