Bulkhead

Problem

One misbehaving caller or workload consumes all your resources (threads, connections, memory) and starves everyone else.

Context

A shared resource pool + heterogeneous workloads = correlated failure. One expensive query eats the whole DB connection pool.

Solution

Partition resources by workload class. Give each caller/workload its own pool (threads, connection pool, memory bucket). When one workload is misbehaving, its pool exhausts — others are unaffected.

Trade-offs

• Wasted capacity: each partition needs its own headroom
• Complex to configure — how many partitions, how big?
• Cross-partition orchestration is harder

Failure modes

• Sizing mistakes: partition too small, legitimate workload throttled
• Cross-cutting concern (auth) still shared — one point of failure remains
• Config drift over time

When to use

• Multi-tenant systems (per-tenant pools)
• Heterogeneous workloads (fast queries vs expensive queries)
• Any shared resource pool that could be starved

When NOT to use

• Homogeneous workloads — one pool is fine
• Small-scale systems — over-engineering