What are the real costs of adopting per-dependency bulkheads across a service with many downstream calls, and under what circumstances would you deliberately choose NOT to bulkhead a particular dependency?

## The pattern is not free The bulkhead pattern is not free, and treating it as a default you apply uniformly to every downstream call is itself a common mistake, so it's worth being precise about what it costs and when the cost isn't justified by the benefit. ## Cost one: resource fragmentation The most direct cost is **resource fragmentation**. Each bulkhead partition reserves capacity — threads, connections, or semaphore permits — that is unavailable to any other partition even when idle. In a service with, say, thirty downstream dependencies, bulkheading every single one means thirty separately-sized pools, each provisioned with enough headroom to handle its own peak load independently, which in aggregate requires substantially more total capacity than one well-managed shared pool sized for the same aggregate throughput (because a shared pool lets idle capacity for a quiet dependency get borrowed by a momentarily busy one, and partitioning forfeits exactly that sharing). For thread-pool bulkheads specifically, this fragmentation cost is doubled by real execution overhead: - every dedicated thread pool consumes memory for its threads whether busy or idle; - and every call incurs a hand-off/context-switch cost that a call running directly on the caller's own thread (or gated by a cheap semaphore) would not. ## Cost two: operational and configuration surface The second cost is **operational and configuration surface**. Each partition needs its own size, its own timeout, and ideally its own saturation/rejection monitoring so a misconfigured partition can be caught before it causes either false rejections (undersized) or a diluted isolation benefit (oversized) — as covered by proper sizing methodology. Multiply that by dozens of dependencies and you have dozens of knobs that need periodic review as traffic patterns shift, each one a place a team can get it wrong, and a genuine increase in the system's overall configuration complexity that has to be maintained by whoever owns the service. ## When skipping a bulkhead is the right call Given those costs, the circumstances where skipping a bulkhead is the right call cluster around a few patterns. - **First, very low-traffic or rarely-called dependencies**: if a dependency is called at most a handful of times per minute, the realistic worst-case resource consumption even with zero isolation is small and bounded, and the isolation benefit of a dedicated partition is negligible compared to its fixed overhead. - **Second, dependencies with strict, well-enforced timeouts and naturally low concurrency**: if a call can, by construction, never hold more than a handful of resource units for more than a second or two, the blast radius of it going bad is already small without a dedicated partition — the pattern's value is highest precisely for dependencies whose failure mode is 'hangs for a long time consuming a lot of concurrent capacity,' and lowest for ones that can't structurally do that. - **Third, in-process or same-trust-boundary calls** where the 'dependency' is really just a local library or an in-memory cache lookup: there's no real network/remote-failure risk to isolate against, so a bulkhead is solving a problem that doesn't exist for that call. - **Fourth — and this is the systemic version — a service with very few downstream dependencies** (say, one or two): the entire premise of 'an unrelated dependency's failure exhausts resources needed by other, healthy dependencies' barely applies, because there's little 'unrelated' traffic to protect in the first place; a single, well-sized, generously-timed-out shared pool may be entirely adequate. ## The judgment cuts both ways In production, teams that **over-apply** bulkheads tend to discover the cost the hard way: a service with, say, forty bulkheaded dependencies accumulates enough idle-thread memory footprint and per-call context-switch overhead that its own baseline latency and resource usage measurably degrade compared to a design that bulkheaded only the five or six dependencies with real, demonstrated failure risk (based on incident history or known latency variance) and used a cheap semaphore-based cap with solid timeouts, or even a shared pool with a good timeout, for the rest. Conversely, teams that **under-apply** bulkheads — skipping isolation for a dependency that later turns out to have unreliable latency — pay for it in exactly the cascading-exhaustion incident described earlier, so the judgment call genuinely cuts both ways and isn't a matter of 'always bulkhead' or 'never bother.' ## How real systems tune the strength A concrete way this trade-off shows up in real systems: - **Netflix's own guidance around Hystrix** explicitly cautioned against isolating every single dependency with a dedicated thread pool at very large fan-out, recommending semaphore isolation (much cheaper) as the default and reserving thread-pool isolation for dependencies where the extra protection was worth the overhead — an internal acknowledgment that full-coverage thread-pool bulkheading doesn't scale cleanly to dozens of dependencies. - **Similarly, service meshes like Envoy** expose per-upstream-cluster connection/request limits as configuration precisely so teams can tune isolation strength per dependency (tight limits for risky externals, loose or default limits for trusted low-risk internal services) rather than applying one blanket policy everywhere.