Bulkhead Isolation
Partition resources per dependency so one failure can't sink everything.
IntermediatePlatform
Each downstream dependency gets its own connection pool / thread pool / instance group, so a single slow or failing dependency exhausts only its own bulkhead instead of starving requests to every other dependency.
When to use it
- One service calls several downstream dependencies with different risk profiles
- A past incident showed one dependency's slowness taking down unrelated request paths
Trade-offs
- More resource pools to size and monitor instead of one shared pool
- Under-provisioning any single bulkhead throttles that path even when spare capacity exists elsewhere
Components used
API GatewayContainer ServiceManaged App Service
How it works
- Resources — thread pools, connection pools, or whole instances — are partitioned per dependency or per tenant.
- Exhausting one partition affects only the traffic assigned to it; everything else continues with its own reserved capacity.
- Isolation is static and deliberate, trading some efficiency for guaranteed containment.
Used in the wild
- Separating critical and non-critical dependencies so a failing recommendations service cannot block checkout.
- Multi-tenant platforms preventing one noisy tenant from consuming shared capacity.
- Isolating a known-flaky integration from the rest of the application.
Good to know
- Named for the watertight compartments in a ship's hull, which limit flooding to one section — an analogy the Titanic memorably demonstrated the limits of.
- The cost is utilisation: reserved capacity sits idle when its partition is quiet. That waste is the price of the guarantee.
Related patterns
Model Serving with A/B Testing
Route inference traffic across model versions to compare live performance.
CQRS
Separate models and stores for writes and reads.
Blue-Green Deployment
Run two full production environments, switch traffic between them.
Canary Release
Send a small slice of traffic to the new version before a full rollout.