Bulkhead Isolation
Bulkhead isolation partitions resources — thread pools, connections, memory — per tenant or per dependency, so a failure or overload in one partition cannot exhaust the resources of the others.
Definition
Bulkhead isolation is the resiliency pattern that allocates a fixed, separate pool of resources — threads, connections, memory — to each tenant, dependency, or workload class, so that an overload or failure in one bulkhead consumes only its own resources and the others remain available, containing the blast radius.
Context and scope
Applied in multi-tenant SaaS, service-to-service calls, and any system where one tenant or dependency can overload and must not take down the others.
Common misconceptions
- Bulkheads are just thread pools — they are resource partitions; thread pools are one instance, but connections, memory, and rate budgets are also bulkheads
- Bulkheads reduce utilization — they reduce peak utilization; the reserved capacity is the cost of isolation, paid for blast-radius containment
Anti-patterns
- Sharing one thread pool across all tenants, so a slow tenant exhausts the pool and every other tenant fails
- Partitioning so finely that each bulkhead is too small to serve its own peak load, causing failures under normal traffic
Related concepts
Authoritative source
https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead
What it is
Bulkhead isolation is the resiliency pattern that allocates a fixed, separate pool of resources — threads, connections, memory — to each tenant, dependency, or workload class, so that an overload or failure in one bulkhead consumes only its own resources and the others remain available, containing the blast radius. Applied in multi-tenant SaaS, service-to-service calls, and any system where one tenant or dependency can overload and must not take down the others. Reliability is a probabilistic property of a system under load, not a feature you add — it is the result of how failures are designed for, detected, and recovered from.
How it works
Failure is assumed; the design question is the blast radius of each failure mode. Redundancy eliminates single points of failure but introduces consistency and split-brain risks that must be solved explicitly. Error budgets quantify the reliability the system can afford, converting “we should be more reliable” into “we have spent this month’s budget and must choose between features and fixes.” Recovery is rehearsed, not theorized.
When to invest and pitfalls
Invest when downtime has a measurable cost — revenue, trust, or safety. The pitfall is adding redundancy without solving the consistency problem it creates — two copies that disagree are worse than one copy that is wrong. Another is chasing five nines without measuring where the downtime actually comes from, investing in the rare failure while ignoring the common one.