A distributed system often fails because too many things share the same limited resources.

One slow dependency can use up every request thread. One noisy customer can drain the whole connection pool. One optional feature can build such a large queue that important work waits behind it. In each case, the original problem is small, but because everything shares the same capacity, the whole service suffers.

The Bulkhead Pattern, named after the watertight compartments in a ship's hull, prevents that. It splits limited resources into separate pools so a failure stays in one area instead of taking down everything. If one pool is full, the others can keep working.

The design question is simple: how much capacity should any one dependency, feature, customer, or workload be allowed to use before it hurts the rest of the system? This chapter covers how to draw those boundaries.

Consider an e-commerce backend where checkout, cart, and recommendations are handled by the same service. Recommendations call a third-party API. During an incident, that API becomes slow but does not fail immediately.

If all request handlers share one worker pool and one outbound connection pool, recommendation calls can occupy the same resources checkout needs.

The failure path looks like this:

The slow recommendation API is only part of the incident. The bigger problem is that an optional feature was allowed to use resources needed by a high-priority feature.