Bulkhead
Bulkhead
Silver
A bulkhead splits a system's resources — servers, connection pools, threads — into separate pools for different workloads or dependencies, so that when one pool fails or is overloaded, the others keep working.
- Use when
- Isolating a dependency whose failure must not take the rest of the service down · Keeping critical work (taking payments) apart from standard work (browsing) · Stopping one tenant or client from using up a shared service
- Avoid when
- When the less efficient use of resources isn't acceptable · Small systems where extra pools add complexity without a real risk to contain
- Trade-offs
- Contains failures, but each pool needs its own headroom, so overall utilization drops · More pools to size, run and monitor
- Requires
- Timeouts, Load balancer
3 objectives · 9 misconceptions
- explain Explain how separate pools of servers, connections or threads stop a failure or overload in one part from spreading to the rest.
- predict Predict which requests still succeed when one workload overloads a shared pool, and when it overloads only its own partition.
- choose Choose where to draw the partitions — by dependency, by workload priority or by tenant — and weigh the spare capacity each split costs.
- Not true: A shared pool with plenty of spare capacity on average can't be overwhelmed by one noisy workload.
- Not true: One connection pool shared by all of a service's dependencies is safe.
- Not true: A bulkhead keeps the overloaded part working.
- Not true: Splitting resources into separate pools costs nothing extra.
- Not true: Every tenant and every feature should get a partition of its own.
- Not true: With bulkheads in place, circuit breakers and throttling are no longer needed.
- Not true: A bulkhead always means separate servers.
- Not true: A flood in one workload still drags down workloads running on servers of their own.
- Not true: A server pushed past full keeps serving what it can and turns only the excess away.