Skip to content

Bulkhead Pattern

Prime #
676
Origin domain
Computer Science & Software Engineering
Subdomain
failure isolation in distributed systems → Computer Science & Software Engineering

Core Idea

The bulkhead pattern partitions a system into sealed compartments so that a failure inside one compartment cannot propagate to its siblings. Each compartment owns its own bounded slice of a critical shared resource — capacity, memory, threads, money, blood, fuel, attention — and once that slice is exhausted, the compartment fails locally rather than draining the resource pool the rest of the system depends on. The defining commitment is lateral isolation: the boundary runs across siblings of equal status, not between an outside threat and an inside asset. The archetype is the ship hull divided by transverse walls — flood one compartment and the others stay dry, so the vessel lists but does not sink.

The structure has a precise content distinct from generic "resilience." It converts a single shared resource — one connection pool, one bloodstream, one hull, one profit-and-loss account — into several independent slices whose failure modes do not chain. Three abstractions carry the pattern: the resource partition (the dimension along which the shared resource is divided), the blast radius (how far one failure reaches), and cross-partition coupling (any hidden shared dependency that re-links the compartments after the nominal partition). A bulkhead is well-formed only if each partition holds enough resource to keep its compartment viable under normal load, the failure of any one partition is detectable and survivable by the rest, and there is no un-partitioned resource — a common upstream provider, a shared queue, a shared operator — that silently re-couples the compartments. The guarantee a bulkhead provides collapses exactly to the granularity of the smallest shared resource that has not been partitioned.

How would you explain it like I'm…

Sealed Ship Rooms

Big ships are built with walls inside that split them into separate rooms, so if one room fills with water, the others stay dry and the ship doesn't sink. The Bulkhead Pattern is building those inside walls into a system, so that if one part breaks, the break stays trapped there and can't spread to the rest.

Sealed Compartments

Imagine you split your weekly allowance into separate envelopes, one for each day. If you blow all the money in Monday's envelope, you've only lost Monday, because the other envelopes are sealed off and still full. The Bulkhead Pattern works like that for systems: it cuts a shared resource into separate compartments, each with its own slice, so that if one compartment runs out or fails, it fails just locally instead of draining everything. The name comes from ships, whose inside walls keep one flooded room from sinking the whole boat. The key idea is that the walls run between equal parts side by side, not between an outside enemy and an inside treasure.

Lateral Failure Isolation

The Bulkhead Pattern partitions a system into sealed compartments so that a failure inside one cannot propagate to its siblings. Each compartment owns its own bounded slice of a critical shared resource, capacity, memory, threads, money, blood, fuel, attention, and once that slice is exhausted, the compartment fails locally rather than draining the shared pool. The defining commitment is lateral isolation: the boundary runs across siblings of equal status, not between an outside threat and an inside asset, unlike a firewall. The archetype is the ship hull divided by transverse walls, flood one compartment and the others stay dry. Three abstractions carry it: the resource partition (the dimension the resource is divided along), the blast radius (how far one failure reaches), and cross-partition coupling (any hidden shared dependency that re-links compartments). It is well-formed only if each partition holds enough resource to stay viable under normal load, each failure is detectable and survivable by the rest, and no un-partitioned resource silently re-couples the compartments.

 

The Bulkhead Pattern partitions a system into sealed compartments so that a failure inside one compartment cannot propagate to its siblings. Each compartment owns its own bounded slice of a critical shared resource, capacity, memory, threads, money, blood, fuel, attention, and once that slice is exhausted, the compartment fails locally rather than draining the resource pool the rest of the system depends on. The defining commitment is lateral isolation: the boundary runs across siblings of equal status, not between an outside threat and an inside asset. The archetype is the ship hull divided by transverse walls, flood one compartment and the others stay dry, so the vessel lists but does not sink. The structure has precise content distinct from generic resilience: it converts a single shared resource, one connection pool, one bloodstream, one hull, one profit-and-loss account, into several independent slices whose failure modes do not chain. Three abstractions carry the pattern: the resource partition, the dimension along which the shared resource is divided; the blast radius, how far one failure reaches; and cross-partition coupling, any hidden shared dependency that re-links the compartments after the nominal partition. A bulkhead is well-formed only if each partition holds enough resource to keep its compartment viable under normal load, the failure of any one partition is detectable and survivable by the rest, and there is no un-partitioned resource, a common upstream provider, shared queue, or shared operator, that silently re-couples the compartments. The guarantee a bulkhead provides collapses exactly to the granularity of the smallest shared resource that has not been partitioned.

Structural Signature

the shared critical resource — the partition dimension slicing it into sibling compartments — the lateral (peer-to-peer) boundary — the bounded blast radius — the cross-partition coupling that can re-link the slices — the local-failure containment invariant

The pattern is present when each of the following holds:

  • A shared critical resource. Some pooled quantity — capacity, threads, memory, money, blood, fuel, buoyancy — is depended on by the whole system, such that its system-wide exhaustion is fatal.
  • A partition along a chosen dimension. The resource is divided into slices, each owned by one compartment; the dimension of the cut (per-dependency, per-tenant, per-entity) is an explicit design choice.
  • Lateral (sibling) boundaries. The walls run across peers of equal status, not between an outside threat and an inside asset — distinguishing this from perimeter containment, series defense-in-depth, modularity, and redundancy.
  • A bounded blast radius. Each compartment is sized to stay viable under normal load, and the exhaustion or failure of any one slice is bounded to that slice rather than draining the pool.
  • No hidden cross-partition coupling. The invariant holds only if no un-partitioned shared dependency — a common upstream, queue, operator, or vendor — silently re-links the compartments after the nominal partition.
  • Detectable local failure. A failed compartment is identifiable as a local event, so the rest of the system can reason about its remaining capacity.

Composed, these convert one shared resource whose system-wide depletion is fatal into independent slices; the guarantee is exactly as strong as the least-partitioned shared resource, traded against the statistical-multiplexing efficiency lost to partitioning.

What It Is Not

  • Not containment. containment is a perimeter against a realized hazard (inside threat, outside asset); bulkheads run laterally between peers and isolate at the resource level whether or not any hazard exists.
  • Not redundancy. redundancy provides spare copies so a failure has a backup; bulkheading requires no copy — only that one compartment's failure not propagate to its siblings. Isolation, not duplication.
  • Not modularity. modularity is about clean, recombinable interfaces; bulkhead compartments are often identical replicas whose load-bearing property is isolation-under-failure, not interface cleanliness.
  • Not a circuit breaker. circuit_breaker trips a failing path off after detecting trouble (a temporal, threshold response); a bulkhead is a static structural partition that bounds blast radius continuously, with no tripping event.
  • Not a bottleneck or load balancer. A bottleneck caps throughput at the slowest stage; load_balancing spreads work across capacity. Bulkheading deliberately forfeits statistical multiplexing to wall off failure — the opposite of pooling for efficiency.
  • Common misclassification. Declaring a system "bulkheaded" because a visible resource is sliced, while an un-partitioned shared dependency (one database, one operator, one upstream limit) silently re-links every compartment. The guarantee collapses to the granularity of the least-partitioned shared resource.

Broad Use

  • Naval architecture — the literal origin: transverse and longitudinal bulkheads partition the hull so a holed compartment floods to equilibrium without transferring water to its neighbors; the Titanic is studied as a partial-bulkhead failure because the partitions did not extend high enough.
  • Distributed software — separate thread pools, connection pools, or process groups per downstream dependency, so one slow dependency cannot starve every caller.
  • Fire and electrical safety — fire-rated compartmentation in buildings, fuel-tank partitioning in aircraft wings, and separate circuits behind separate breakers, so a fire, leak, or short cannot walk across the whole structure.
  • Corporate and financial structure — ring-fenced legal entities, special-purpose vehicles, and retail-versus-investment-bank separation, so one subsidiary's failure cannot drag down its siblings.
  • Public health — quarantine cohorts, school bubble groups, and separate hospital ventilation zones partition a population so a local outbreak does not reach the whole.
  • Biology — the blood-brain barrier, separate vascular beds, cellular and organellar membranes, and septated fungi whose hyphae can lose a segment without losing the colony.
  • Organizational design — autonomous teams or business units with their own budgets and runways, so a failing initiative does not consume the resources keeping the rest alive.

In each the substrate differs entirely — water, threads, fire, capital, pathogens, cytoplasm, budget — yet the load-bearing property is the same: a shared resource cut into sibling slices whose exhaustion stays local.

Clarity

The pattern names the precise design choice that vague language about "resilience" or "robustness" leaves implicit: which resource is being partitioned, and along which dimension? That single question disciplines the whole analysis, because the answer tells you both what the bulkheads protect against and what they cost. A claim that a system is "fault-tolerant" is converted into the checkable specification "this resource is divided into N slices of these sizes, and the worst-case loss is bounded by one slice."

The clarity extends to a sharp separation of bulkheading from its neighbors. It is not containment (a perimeter against a realized hazard), because bulkheads isolate siblings at the resource level whether or not a hazard exists. It is not defense in depth (series layers between a threat and an asset), because bulkheads are parallel compartments at the same level. It is not modularity (clean recombinable interfaces), because bulkhead compartments are often identical replicas whose load-bearing property is isolation-under-failure, not interface cleanliness. And it is not redundancy (spare copies), because bulkheading requires only that one failure not propagate, not that any copy exist. Making these distinctions explicit prevents the common error of assuming a system has lateral failure isolation because it has one of the adjacent properties.

Manages Complexity

Bulkheading lets a designer accept that any one compartment will sometimes fail while still bounding the system's worst-case loss to one compartment's worth. The reasoning about a single bulkhead stays local — how big should this slice be, and what maximum demand can it absorb before degrading? — while the overall guarantee composes additively, since total loss is bounded by the slice size rather than the system size. The cognitive load of "what could possibly bring down the whole system?" collapses to the far smaller question "what could possibly cross a bulkhead?"

That smaller question is itself structured: it directs attention to hidden re-couplings. Because the guarantee degrades to the granularity of the smallest un-partitioned shared resource, the management of a bulkheaded system reduces to an audit — find what every compartment touches (the operator, the database, the network fabric, the parent guarantee, the same vendor) and recognize that resource as the place where the guarantees stop. Complexity is managed not by reasoning about the whole interaction graph but by enumerating the shared substrate beneath the partitions.

Abstract Reasoning

Bulkhead reasoning is fundamentally a search for hidden re-couplings. The key abstractions — resource partition, blast radius, cross-partition coupling — generate a recurring diagnostic: identify the critical shared resource that would take the whole system down if depleted; identify the dimension along which it is (or should be) sliced; and then hunt for any common dependency that re-links the slices after the nominal partition. A bulkhead's guarantees are exactly as strong as the least-partitioned shared resource, so the analyst's task is to find that resource rather than to admire the partitions that are visible.

The pattern also installs a reasoning about cost. Partitioning a pool into N slices reduces statistical-multiplexing efficiency, so total throughput in the no-failure case is lower than an unpartitioned pool would yield. The abstract question is therefore always a trade: is the worst-case bounded loss worth the average-case slack? And it installs a granularity question — too coarse and the blast radius is the whole system, too fine and the overhead of partitions overwhelms the resource — whose answer is usually "a unit of meaningful customer or mission loss." These questions transfer to any system with a shared critical resource, independent of what the resource is.

Knowledge Transfer

The pattern carries interventions, not merely vocabulary, and they port unchanged across substrates. Size each compartment for survival, not for fairness — slices need not be equal; each should be just large enough to keep its compartment alive under realistic load. Audit for the silent shared resource — find what every compartment touches (operator, database, network fabric, parent guarantee, vendor), because that un-bulkheaded substrate is where the guarantees stop. Trade utilization for isolation — accept the statistical-multiplexing penalty of partitioning when worst-case bounded loss is worth the average-case slack. Place the boundary at the right granularity — usually a unit of meaningful customer or mission loss, neither so coarse that the blast radius is the system nor so fine that partition overhead dominates. Detect compartment failures as local events — a system that cannot tell which compartment failed cannot reason about its remaining capacity, and its bulkheading becomes ceremonial.

The transfer holds because the underlying object — a shared critical resource cut into sibling slices, with exhaustion bounded to one slice and no hidden re-coupling — is identical whether the slices are thread pools, hull compartments, legal entities, quarantine cohorts, or fungal segments. A platform engineer giving each downstream dependency its own capped thread pool, a naval architect extending bulkheads above the waterline, and a bank ring-fencing its retail arm are doing the same structural work: convert one shared resource whose system-wide depletion is fatal into several independent slices whose failure stays local, then verify that no un-partitioned resource silently re-links them. The strip-the-jargon test holds cleanly — drop the word "bulkhead" and the pattern is "partition the shared resource so one compartment's failure stays local" — which is why the same five interventions recognize the same structure in ships, software, and balance sheets without translation.

Examples

Formal/abstract

Consider a service with a single thread pool of \(N\) worker threads serving requests to \(k\) downstream dependencies. The shared critical resource is the thread pool; without partitioning, if one dependency \(D_1\) hangs (stops responding), every request to \(D_1\) ties up a worker until it times out, and under sustained load all \(N\) threads end up blocked on \(D_1\) — the blast radius is the whole service, because callers to the healthy \(D_2 \ldots D_k\) now find no free worker. The bulkhead applies the partition along a chosen dimension (per-dependency): give each dependency its own sub-pool of \(N/k\) threads. Now \(D_1\)'s hang can exhaust at most its own \(N/k\) slice — the bounded blast radius and local-failure containment invariant — while \(D_2 \ldots D_k\) keep their threads and stay responsive; the service degrades (loses \(D_1\)'s function) rather than failing whole. The cost is exact and computable: partitioning forfeits statistical multiplexing, so the maximum concurrent capacity any one dependency can borrow drops from \(N\) to \(N/k\), lowering no-failure throughput in exchange for the isolation guarantee. The hidden cross-partition coupling check is the load-bearing part: if all sub-pools share one upstream connection limit, one database, or one mutex, the partition is ceremonial — the guarantee collapses to the granularity of that un-partitioned resource, which is the prime's invariant that protection is only as strong as the least-partitioned shared resource.

Mapped back: The per-dependency thread-pool instantiates every role — the thread pool as shared resource, per-dependency sub-pools as the lateral partition, one hung dependency confined to its slice as the bounded blast radius, the lost multiplexing as the isolation cost, and a shared connection limit as the cross-partition coupling that would void the guarantee.

Applied/industry

Naval architecture and financial structure show the identical pattern in water and capital. A ship's hull is divided by transverse bulkheads into watertight compartments; the shared critical resource is buoyancy, and lateral isolation means a holed compartment floods to equilibrium without transferring water to its peers — the vessel lists but stays afloat. The Titanic is the canonical cross-partition / blast-radius failure: its bulkheads did not extend high enough above the waterline, so once enough forward compartments flooded, water spilled over the tops from one compartment to the next — an un-partitioned vertical dimension (height) silently re-linked the slices, and the guarantee collapsed exactly to that least-partitioned resource. The applied lesson — extend the boundary so no un-partitioned dimension re-couples the compartments — is the prime's "audit for the silent shared resource" intervention. In banking, ring-fencing isolates a retail subsidiary from its investment-banking siblings so that trading losses in one legal entity cannot drain the deposits the other depends on; the shared resource is the firm's capital, the partition dimension is the legal-entity boundary, and the cross-partition coupling to watch is an intra-group guarantee or shared liquidity line that would re-link the ring-fenced units. Distributed-software circuit-breakers-plus-bulkheads complete a third domain, isolating per-tenant capacity so one noisy tenant cannot starve the rest.

Mapped back: Ship hulls and bank ring-fences realize the prime end-to-end — buoyancy and capital as shared critical resources, transverse walls and legal entities as lateral partitions, list-but-float and contained-loss as bounded blast radius — while the Titanic's over-topping shows the cross-partition coupling (un-partitioned height) collapsing the guarantee to its weakest dimension.

Structural Tensions

T1 — Isolation versus statistical multiplexing (scalar). Partitioning a pool into N slices bounds worst-case loss but forfeits the ability of any compartment to borrow idle capacity from its siblings, so no-failure throughput falls. The failure mode is over-partitioning: slicing so finely that each compartment is starved under normal load and the system fails more often (locally) than the unpartitioned pool would fail globally. Diagnostic: compare per-slice peak demand to slice size; if compartments routinely saturate while the aggregate pool had headroom, the isolation has cost more capacity than the contained blast radius is worth.

T2 — Nominal partition versus hidden re-coupling (coupling). The whole guarantee collapses to the granularity of the least-partitioned shared resource, and the dangerous couplings are the invisible ones — a common upstream, a shared mutex, one operator, one vendor. The failure mode is declaring a system bulkheaded because the visible resource is sliced while an un-partitioned substrate silently re-links every compartment (the Titanic's un-bounded vertical dimension). Diagnostic: enumerate what every compartment touches; any resource on that list is where the isolation actually stops, regardless of how cleanly the nominal dimension was cut.

T3 — Partition dimension versus failure dimension (scopal). A bulkhead isolates along the dimension it was cut, but failures arrive along whatever dimension they choose; a per-tenant partition gives no protection against a failure that spans tenants (a poisoned shared library, a correlated dependency outage). The failure mode is cutting along the convenient dimension rather than the one failures actually travel, producing partitions that look protective but are orthogonal to the real propagation path. Diagnostic: ask along which dimension a realistic failure spreads, then check whether the partition runs across that dimension or merely beside it.

T4 — Blast-radius containment versus correlated failure (sign/direction). Bulkheads bound independent compartment failures, but a common-mode shock can fail many compartments at once, and partitioning offers no defense against simultaneity — it may even worsen it by denying compartments the ability to pool reserves against a shared stress. The failure mode is trusting per-compartment containment against a correlated event (a region-wide outage, a market-wide run on every ring-fenced entity). Diagnostic: ask whether compartment failures are independent or driven by a shared cause; under correlation, the bulkhead's "one slice at most" guarantee does not hold and redundancy or a shared buffer may be the better prime.

T5 — Local-failure detection versus silent degradation (measurement). The containment guarantee is only usable if a failed compartment is detectable as a local event; a system that cannot tell which slice failed cannot reason about its remaining capacity, and the bulkheading becomes ceremonial. The failure mode is a compartment that exhausts or degrades silently, so the system continues routing work to a dead slice while believing full capacity remains. Diagnostic: ask whether each compartment's health is independently observable; if failures are only visible in aggregate, the partition isolates the fault but hides it, defeating the reasoning the bulkhead was meant to enable.

T6 — Static partition versus shifting load (temporal). Compartments are sized for an expected load distribution, but demand shifts over time, and a fixed partition that was right at design time becomes wrong as one compartment's traffic grows past its slice while a sibling sits idle. The failure mode is a stale partition that throttles the now-hot compartment and forfeits the idle sibling's capacity, manufacturing local failures the unpartitioned pool would have absorbed. Diagnostic: track per-slice utilization over time; persistent skew between compartments means the partition dimension or sizing has drifted out of date and needs re-cutting or dynamic resizing.

Structural–Framed Character

The bulkhead pattern sits at the structural pole of the structural–framed spectrum: it is pure compartmentalization-for-isolation structure — a shared critical resource partitioned into sibling slices so one slice's exhaustion stays local — and its frontmatter grade (label structural, aggregate 0.0, all five criteria zero) records that every diagnostic points one way.

Walk them. The pattern carries no home vocabulary that must travel with it: the same lateral-isolation structure is told in the naval architect's watertight hull, the platform engineer's per-dependency thread pool, the banker's ring-fenced legal entity, the epidemiologist's quarantine cohort, and the mycologist's septated hyphae — each in its own words, and the entry's own strip-the-jargon test confirms it ("drop the word bulkhead and the pattern is partition the shared resource so one compartment's failure stays local"). It carries no evaluative weight: a resource partition is neither good nor bad until you specify what it protects and what statistical-multiplexing efficiency it costs; the prime is a value-neutral trade-off. Its origin is formal — a shared resource, a partition dimension, a lateral boundary, and a cross-coupling check — with no appeal to human norms; the literal hull and the bacterial membrane make plain there is no institutional referent. It is not human-practice-bound: the mechanism runs identically in buoyancy, blood, capital, threads, and cytoplasm, requiring no human role for the containment to obtain. And invoking it merely recognizes a partition (or its absence) already present in any system with a pooled critical resource — it imports no interpretive frame, only the observation that the guarantee is exactly as strong as the least-partitioned shared resource. On every diagnostic, it reads structural.

Substrate Independence

The bulkhead pattern is fully substrate-independent — composite 5 / 5 on the substrate-independence scale. Its content is pure compartmentalization-for-isolation structure — a shared critical resource partitioned into sibling slices so one slice's exhaustion stays local — and the strip-the-jargon test holds cleanly ("partition the shared resource so one compartment's failure stays local"), so it is recognized rather than translated. Domain breadth is maximal: lateral isolation between siblings sharing a critical resource governs watertight hulls in naval architecture, per-dependency thread pools and process groups in distributed software, fire compartmentation and fuel-tank partitioning in safety engineering, ring-fenced legal entities in corporate finance, quarantine cohorts in public health, blood-brain barriers and septated hyphae in biology, and autonomous-team budgeting in organizational design — water, threads, fire, capital, pathogens, cytoplasm, and budget all carrying the identical isolation property. Structural abstraction is total: the pattern reduces to a shared resource, a partition dimension, a lateral boundary, and a cross-coupling check, with no domain commitment — the guarantee is exactly as strong as the least-partitioned shared resource regardless of medium. And transfer evidence is heavily documented through concrete carriers — the per-dependency sub-pool, the Titanic's over-topping as the canonical cross-partition failure, bank ring-fencing, and bacterial septation are the same five interventions recognized in ships, software, and balance sheets without translation. Maximal on every component, it is a canonical 5.

  • Composite substrate independence — 5 / 5
  • Domain breadth — 5 / 5
  • Structural abstraction — 5 / 5
  • Transfer evidence — 5 / 5

Neighborhood in Abstraction Space

Bulkhead Pattern sits among the more crowded primes in the catalog (27th percentile for distinctiveness): several abstractions describe nearly the same structure, so a description that fits it will tend to fit its neighbors too — transporting it usually means disambiguating within this family rather than landing on it exactly.

Family — Shared Resources & Boundary Spillover (19 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-06-14

Not to Be Confused With

The most important distinction is from redundancy, because both are resilience primes and both are reached for under the heading "make the system fault-tolerant." They guarantee different things. redundancy provides spare copies of a component so that when one fails, a backup carries the load — its invariant is continuity through substitution. Bulkheading provides isolation so that when one compartment fails, the failure does not drain the resource its siblings depend on — its invariant is bounded blast radius. The two are orthogonal: a system can be redundant but not bulkheaded (two replicas sharing one connection pool, so one replica's runaway starves the other), and bulkheaded but not redundant (four walled-off compartments, none with a backup, where losing one merely degrades the service rather than failing it whole). The practitioner consequence is that they answer different questions — redundancy asks "is there a spare?", bulkheading asks "can one failure spread?" — and treating them as interchangeable produces the common error of adding replicas while leaving a shared resource un-partitioned, so a single exhaustion still takes down every replica at once. Bulkheading requires no copy; redundancy requires no isolation; robust systems usually need both, deliberately.

A second genuine confusion is with containment. Both wall off failure, and the words are near-synonyms in casual use, but the geometry of the boundary is opposite. containment is a perimeter drawn between an inside and an outside — a hazard is realized and the boundary keeps it from escaping (a quarantine, a firewall, a blast wall), so the boundary's two sides have unequal status (protected asset versus threat). Bulkhead boundaries run laterally between siblings of equal status, and they isolate at the resource level whether or not any hazard is present — the partition exists so that if any compartment fails, its failure stays local, with no privileged "inside." The distinction is load-bearing: containment is organized around a specific realized threat and its direction of spread, while bulkheading is organized around a shared resource and the symmetric possibility that any compartment could be the one to fail. A practitioner who models a lateral isolation problem as containment will draw a perimeter (defending a core against an exterior) when the actual need is peer-to-peer partitioning of a pooled resource — and will miss that the dangerous coupling is not a perimeter breach but an un-partitioned shared dependency beneath all the compartments.

A third confusion worth marking is with modularity. A bulkheaded system looks modular — it is decomposed into parts with boundaries — so the two are easily conflated. But modularity optimizes for clean, recombinable interfaces (parts that can be understood, swapped, and reassembled independently), whereas bulkhead compartments are frequently identical replicas whose value is not interface cleanliness at all but isolation under failure. A perfectly modular system with elegant interfaces can have zero failure isolation if all modules share one thread pool or one database; conversely, crude undifferentiated compartments with ugly interfaces can bulkhead beautifully. The practitioner error is assuming that because a system is well-modularized it must be fault-isolated, when the property that bounds blast radius is resource-partitioning, not interface quality.

For a practitioner these distinctions decide the design. Read bulkheading as redundancy and you add spares while a shared resource still couples every copy; read it as containment and you build a perimeter where you needed peer partitioning; read it as modularity and you assume clean interfaces buy failure isolation they do not. The unifying test is the prime's own diagnostic: is a shared critical resource cut into sibling slices such that one slice's exhaustion stays local — and is there any un-partitioned dependency that silently re-links them? Only then is it the bulkhead pattern, distinct from spares, perimeters, and interfaces.

Solution Archetypes

No catalogued solution archetypes reference this prime yet.