Bulkhead

Overview

The bulkhead pattern isolates resources so a failure or overload in one part of a system cannot consume everything and take down the rest. The name comes from ships, whose hulls are divided into watertight compartments: a breach floods one compartment, not the whole ship.

In software, bulkheads are separate thread pools, connection pools, concurrency limits, queues, or even separate deployments per dependency, feature, or customer tier. If the recommendations service hangs, only the resources dedicated to it are exhausted, and checkout keeps working.

When to use it

• Services calling several dependencies of different criticality.
• Multi-tenant systems where one tenant must not starve others.
• Separating critical from non-critical workloads.
• Protecting shared infrastructure (databases, thread pools).

Where it shows up in interviews

Where it is used in real software

Key terms

Resource isolation

Dedicated pools or limits per consumer or dependency.

Semaphore bulkhead

Limit concurrent calls with a counter.

Thread-pool bulkhead

Separate thread pool per dependency.

Cell

Independent full stack serving a subset of users.

Noisy neighbor

A workload consuming shared resources unfairly.

How it works, step by step

1. 1
   Identify shared resources

   Threads, connections, CPU, queues, databases.

2. 2
   Classify by criticality

   Checkout vs recommendations; paying vs free tier.

3. 3
   Allocate separate limits

   Pools or semaphores sized per dependency.

4. 4
   Reject when full

   Fail fast with fallback instead of queuing forever.

5. 5
   Monitor saturation

   Alert when a bulkhead is frequently full.

Shared vs bulkheaded thread pool

200 request threads; recommendations service hangs

The bulkhead converts a total outage into a degraded feature.

Implementation

1// Semaphore bulkhead: limit concurrent calls per dependency and reject when full2export class Bulkhead {3  private active = 0;4  constructor(private readonly maxConcurrent: number, private readonly name: string) {}5 6  async run<T>(fn: () => Promise<T>, fallback: () => T): Promise<T> {7    if (this.active >= this.maxConcurrent) {8      metrics.increment("bulkhead.rejected", { name: this.name });9      return fallback();10    }11    this.active++;12    try {13      return await fn();14    } finally {15      this.active--;16    }17  }18}19 20const recommendationsBulkhead = new Bulkhead(20, "recommendations");21const inventoryBulkhead = new Bulkhead(100, "inventory");22 23const recs = await recommendationsBulkhead.run(() => withTimeout(recsClient.similar(id), 200), () => []);

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Sizing bulkheads by guesswork.

  Fix: Use Little's Law with measured rates and latencies.

• Unbounded queues in front of bulkheads.

  Fix: Queues hide saturation and add latency; bound them.

Interview questions

Practice problems