# Bulkheads The Bulkheads pattern partitions a system's resources so that a failure or overload in one partition can't use up the resources of the others. The name comes from ships: the hull is divided into watertight compartments, so a breach floods one section instead of sinking the ship. [[Michael Nygard]] describes it as one of the stability patterns in [[Release It! (Book)|Release It!]]. ## Why it matters Without partitions, every caller shares the same pool of threads, connections and instances. When one dependency becomes slow or unresponsive, the requests waiting on it hold those shared resources until the pool is empty, and calls to perfectly healthy dependencies start failing too. That's the start of [[Cascading Failures]]. A bulkhead caps the damage: only the partition tied to the broken dependency runs dry. [[Timeouts (software)|Timeouts]] limit *how long* a resource can be stuck; bulkheads limit *how many* resources can be stuck at once. A [[Circuit Breaker]] then stops sending calls to the dependency altogether. ## Where to put the walls - **Inside a caller**: a separate thread pool, connection pool or semaphore per dependency. Libraries like Resilience4j (Java) and Polly (.NET) provide this - **Between consumers**: separate service instances or queues for different clients, so that one client flooding its instance leaves the others alone. A common split is critical versus standard traffic - **Cells**: AWS's cell-based architecture runs several complete, independent copies of a workload (cells) that share no state, each serving a subset of customers behind a thin routing layer. With 10 cells, a failure in one (a bad deployment, for example) leaves 90% of requests unaffected - **Shuffle sharding**: AWS assigns each customer a random combination of workers instead of a fixed shard. With 8 workers and 2 per customer there are 28 combinations, so a problem caused by one customer reaches about 1/28th of the others, seven times better than plain sharding ## Trade-offs - **Idle capacity.** Capacity reserved for one partition sits idle while another is starved. Microsoft's guidance says the pattern doesn't fit when less efficient use of resources isn't acceptable - **Sizing.** Every partition needs a size, and getting it wrong either wastes capacity or makes the partition the new bottleneck - **Where to draw boundaries.** Microsoft suggests aligning partitions with business boundaries (bounded contexts in domain-driven design) rather than technical ones only ## References - Michael Nygard, Release It! Second Edition, Pragmatic Bookshelf, 2018 (Stability Patterns chapter): https://pragprog.com/titles/mnee2/release-it-second-edition/ - Microsoft Azure Architecture Center, Bulkhead pattern: https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead - AWS Well-Architected, "What is a cell-based architecture?": https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/what-is-a-cell-based-architecture.html - Colm MacCárthaigh, "Workload isolation using shuffle-sharding", Amazon Builders' Library (2019): https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/ ## Related - [[Cascading Failures]] - [[Circuit Breaker]] - [[Timeouts (software)]] - [[Load Shedding]] - [[Fault Tolerance]] - [[Loose Coupling]] - [[Release It! (Book)]] - [[Michael Nygard]] - [[Software Architecture]] - [[Rate Limiting]]