Bulkhead
Table of Contents
This page defines the service architecture pattern Bulkhead in the pattern language. Resources are split into isolated pools, so one overloaded caller, tenant or dependency cannot take all of them. In ORE Studio the reporting design gives each tenant its own share of a step service, and compute routes work by platform.
1. Also known as
- Isolation pools.
- Partitioned capacity.
2. Context
A service shares threads, connections and workers between many callers and many dependencies. One of them can become slow or demanding.
3. Problem
How does a service stop one source of load from exhausting what every other source needs?
4. Forces
- Shared pools use capacity well until one user takes all of it.
- Fixed pools waste capacity when idle.
- A slow dependency holds its callers' resources while it waits.
5. Solution
Divide the resources into pools and bound each one: per tenant, per dependency, per platform. A call takes a slot from its own pool, and waits or is refused when the pool is full. A slow dependency then holds only its own pool, and a busy tenant only its own share.
Figure 1: Bulkhead: tenant A's pool waits on a slow owner while tenants B and C keep their capacity.
Source: [[./pattern_bulkhead.puml][pattern_bulkhead.puml]]. Regenerate with
plantuml -tpng doc/knowledge/service_architecture_patterns/pattern_bulkhead.puml.
6. Failure handling
| Concern | What the pattern does |
|---|---|
| Errors | A full pool refuses or queues a call; the error names the pool. |
| Timeouts | A slot held past its timeout is released by the timeout. |
| Retries | A refused call may be retried later, within the caller's budget. |
| Idempotency | Does not apply: the pool decides capacity, not repetition. |
| Observability | Each pool's use and queue length are measured. |
7. Pitfalls
- Pools too small. A tenant waits while capacity sits idle.
- One pool for everything. The bulkhead does not exist.
- A wait that counts against a deadline. A step queued for its pool can expire before it runs; size pools inside the budget.
8. Security
Availability: one tenant cannot deny service to another by load.
9. Resulting context
- Benefits
- One slow dependency or busy tenant cannot take down the rest.
- Liabilities
- Idle capacity in quiet pools, and limits to size and tune.
10. In ORE Studio
- Report execution at scale — per-tenant step limits in each replica, and dedicated compute pools.
- Compute job lifecycle — assignments are routed per platform, so one platform's backlog does not hold another's.
- Delivery threads enqueue and a bounded pool runs the handlers — requests, events and durable deliveries each have their own bounded queue in front of the worker pool.
11. Related patterns
- Fair Share — how capacity is divided.
- Throttling — the limit at the door.
- Timeout — releases a held slot.
12. Sources
- Michael T. Nygard, Release It!, second edition, Pragmatic Bookshelf, 2018, chapter 5, "Stability Patterns" — Bulkheads.
- Microsoft, Azure Architecture Center, Cloud design patterns, Bulkhead pattern.
13. See also
- Service architecture patterns — the structure note that orders this pattern language, and where to read this page in it.