Intent

Isolate components of a system so that failure in one does not cascadingly fail the entire application, analogous to ship bulkheads preventing water from flooding the entire vessel. Partitions resources so that failure in one area cannot deplete shared pools needed by others.

Problem

In distributed systems, a single slow or failed downstream service can exhaust thread pools, saturate connections, and cause cascading failures that take down the entire application. Without isolation, all services share the same resource pools and failure modes.

Forces

Solution

Bulkhead Framework

Isolate components of a system so that failure in one does not cascade to the entire application, analogous to ship bulkheads preventing water from flooding the entire vessel.

Key Strategies

1. Connection Pool Isolation

Maintain separate connection pools per downstream service. A slow service cannot exhaust the connection pool for other services. Configure pool sizes per service criticality.

2. Thread Pool Isolation

Dedicated thread pools per service or component. Blocking calls in one area cannot starve threads in others. Use bounded queues and backpressure.

3. Resource Budget Allocation

Assign fixed quotas of memory/CPU per service. Ensure critical services always have resources available. Use cgroups, namespaces, or container limits.

4. Circuit Breaker + Bulkhead

Combine with Circuit Breaker for double protection. Bulkhead prevents resource exhaustion. Circuit Breaker prevents calls to failed services.

When to Use

Any service with multiple downstream dependencies
Preventing cascading failures in distributed systems
When some dependencies are more critical than others
When thread pool or connection pool exhaustion is a frequent issue

When Not to Use

Very small services with a single dependency
When all dependencies have similar criticality and failure modes
If the overhead of isolation outweighs the risk of cascading failures

Cost Profile

| Category | Assessment | |----------|-----------| | Infrastructure | Low — just separate pool management in service code | | Operational | Low — once configured, self-regulating | | Cognitive | Medium — determining proper isolation boundaries |

Real-World Examples

Hystrix thread pools at Netflix: Isolation of failure domains
Spring Boot separate thread pools: Per-service thread pool configuration

Alternatives

Circuit Breaker — Fail fast when downstream is overwhelmed
Timeout & Retry — Time-bound retries without state
Dependency Isolation — Network-level isolation

✓ When to Use

•Any service with multiple downstream dependencies
•Preventing cascading failures in distributed systems
•When some dependencies are more critical than others
•Thread pool or connection pool exhaustion is a frequent issue

✗ When Not to Use

•Very small services with a single dependency
•When all dependencies have similar criticality and failure modes
•If the overhead of isolation outweighs the risk of cascading failures

Pros

+Prevents cascading failures across services
+Allows critical services to continue operating
+Well-understood pattern with proven implementations
+Combines well with Circuit Breaker

Cons

−Requires planning: Need to determine isolation boundaries upfront
−Resource overhead: Multiple pools may underutilize resources
−Complexity: More configuration and monitoring required
−Potential for resource fragmentation if not tuned properly

Cost Profile

Infrastructure

Operational

Cognitive

Failure Modes

Real-World Examples

Alternatives

Related Patterns

Competency Domains

reliability opssecurity compliance