On the South River there used to run a type of old wooden cargo ship — broad-beamed, deep-drafted, carrying several thousand catties of rice in a single trip.

In the early days every ship was open-hold: the hull was one big belly, rice stacked from bow to stern with nothing in between. Loading was easy, and for more than a decade nothing went wrong.

Until one autumn night, an open-hold ship scraped a submerged reef.

The breach was small — a fist-sized hole on the port side near the stern. Water rushed in and began soaking the rice at the back. The captain ordered his crew to plug it: cotton wadding, wooden boards, hammers swinging in the dark. They worked for half an hour. The water kept coming.

But the real problem was not whether they could plug the hole. The real problem was this: once water entered the stern, it flowed freely along the open floor toward the bow. An open hold has nothing to stop it. Half an hour later, the entire bottom of the ship was underwater, and every sack of rice was ruined. The hull sank lower, the waterline crept higher, and eventually the breach itself was submerged — now they could not even reach it to plug.

Three thousand catties of rice, lost. The ship, sunk.

At the next dock over, a ship of roughly the same size had also scraped a reef that same year. Its captain was an old master who, when the ship was built, had insisted on nailing a wooden partition wall across the hull every five feet, dividing the open hold into six independent compartments. Each wall was sealed tight — water could not pass.

When that ship struck the reef, the breach was in compartment four. Water flooded compartment four and filled it in an hour. But compartment three was dry. Compartment five was dry. The bow and stern were bone dry. The captain had his crew haul the cargo out of compartment four and dump it overboard — five hundred catties of rice gone, but the ship stayed afloat, and the remaining twenty-five hundred catties arrived safely at the far bank.

Later someone asked the old master: “Don’t those six partition walls get in the way? You have to load one compartment at a time and unload one at a time — much slower than an open hold.”

The old master said: “Slower, yes. But an open-hold ship, one hole sinks the whole vessel. A partitioned ship, one hole sinks one compartment. Would you rather load fast and sink fast, or load slow and arrive?”

Someone else asked: “Then why not thirty compartments — wouldn’t that be even safer?”

The old master shook his head. “Too many compartments and each one barely fits a few sacks. The crew can’t turn around inside. Loading takes longer than walking. And the partition walls themselves take up space — thirty walls, and you’ve lost a tenth of your cargo hold. How many compartments to build is a craft, not a contest for the most.”

— By now you have probably recognized it: this is the bulkhead pattern.

What it is

The name bulkhead comes directly from shipbuilding: transverse partition walls divide a cargo hull into independent watertight compartments. One compartment flooding does not affect the others, and the ship does not sink from a single breach.

In software engineering, the bulkhead pattern is a resource isolation strategy: partition a system’s resources (thread pools, connection pools, memory, CPU quotas) into independent compartments, each serving a different caller or function. When work in one compartment goes wrong — a downstream service times out, a class of requests suddenly spikes — it can only exhaust the resources inside its own compartment. It cannot drag down the others.

The most common implementation is separate thread pools. Suppose an API service calls three downstreams: payments, inventory, and recommendations. If all three share one thread pool and the recommendation service slows down, every thread blocks on recommendation calls, and payments and inventory become unavailable too — a non-critical service has killed the entire system. The bulkhead approach gives each downstream its own pool: 10 threads for recommendations, 20 for payments, 15 for inventory. If recommendations stall, at most 10 threads are consumed; payments and inventory are completely unaffected.

Netflix’s Hystrix (now in maintenance mode, but the ideas live on) was the first to name this pattern bulkhead. Resilience4j’s Bulkhead and ThreadPoolBulkhead are the current standard in the Java ecosystem. In Kubernetes, resource requests and limits are essentially Pod-level bulkheads: each Pod has its own CPU and memory quota; a Pod with a memory leak gets OOMKilled on its own and does not eat memory from other Pods on the node. Istio’s DestinationRule with connectionPool settings is the same idea — capping the maximum connections and concurrent requests to each upstream service.

Why it matters

A system without bulkheads is an open-hold ship: any single component’s failure can exhaust globally shared resources and drag down every other component. This is the classic path of cascading failure — not because everything breaks at once, but because one component slows down, saturates the shared pool, and starves every healthy component of resources.

Bulkhead and circuit breaker are often used together but solve different dimensions of the problem. A circuit breaker answers “should I keep calling this downstream” (fail fast). A bulkhead answers “how much resource can this downstream consume at most” (resource ceiling). One is a traffic switch; the other is a capacity fence. Together they form complete fault isolation.

Compartment granularity is the key design decision. Too coarse (one pool for the entire service) is the same as no bulkhead. Too fine (one pool per API endpoint) explodes management cost, and small pools saturate under normal traffic. In practice, partitioning follows failure domains: calls to the same downstream, queries to the same database, operations with the same risk profile go into one compartment.

Metaphor mapping

• The open-hold cargo ship — a system where all calls share one thread pool / connection pool
• A fist-sized breach — a single downstream service slowing down or failing
• Water flowing freely across the open floor — failure exhausting shared resources, cascading to all functions
• Three thousand catties of rice lost, ship sunk — total system unavailability
• A partition wall every five feet — bulkhead: isolating resources by failure domain
• Six independent watertight compartments — separate thread pools / connection pools / resource quotas
• Compartment four floods, the other five stay dry — failure contained within one compartment
• Five hundred catties lost, twenty-five hundred arrive safely — partial degradation, core functions survive
• “Loading is slower than an open hold” — the operational cost of isolation: configuring, monitoring, tuning each pool
• “Thirty compartments is too many, crew can’t turn around” — over-fine granularity: resource fragmentation, management burden
• “How many compartments to build is a craft” — compartment granularity design: partition by failure domain, not by API