Bulkhead Pattern
Bulkhead: start from the problem
See the responsibilities
Slow image processing occupies every shared worker slot, preventing fast order requests from running. One workload consumes the resources another needs to keep its promise.
This is a workflow and resilience pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Bulkhead addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Bulkhead isolates resource budgets so one area’s exhaustion does not consume every area’s capacity. Bound workers, connections or queues according to the intended failure boundary. Isolation is about budgets, not simply separate module names.
The example gives reports and orders independent single-slot pools. A second report is rejected while an order can still acquire its own slot. It models admission only; it does not run parallel tasks or guarantee enough hardware.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
function pool(limit) {
let active = 0;
return {acquire() { if (active >= limit) return false; active++; return true; }};
}
const reports = pool(1);
const orders = pool(1);
console.log(reports.acquire());
console.log(reports.acquire());
console.log(orders.acquire());Expected output
true
false
trueChoose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it where one dependency, tenant or task type can exhaust shared resources and another must remain able to progress. Choose the boundary from actual contention.
Reserved budgets can leave capacity idle and need tuning. Release acquired resources reliably, including on exceptions and cancellation. A separate queue with unlimited growth still leaves an overload problem.
Distinguish the neighbouring patterns
Rate Limiting controls incoming work under a policy. Bulkhead partitions resource use. Circuit Breaker gates calls to a dependency based on health; it does not reserve independent worker pools.
Follow request admission budgets, dependency-health gating, bounded backlog and waiting to compare the specific responsibility before combining patterns.
For further reading, use Microsoft’s Bulkhead guidance. Compare it with this original example and the guarantee required by your application.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Bulkhead, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside bounded backlog and waiting.
Reaching the recap and completing the quizzes are separate milestones.