Explain Bulkheads & Backpressure in Microservices

6 / 12

resilience

Bulkheads & Backpressure

Isolate failures within bounded resource pools so a noisy neighbor can't starve everyone else.

The bulkhead pattern takes its name from a ship's hull, which is divided into watertight compartments so that a breach in one does not flood the entire vessel. Applied to software, it means partitioning resources — thread pools, connection pools, queues — so that a failure or overload in one part of the system is contained and cannot consume the resources every other part depends on. The problem it prevents is resource starvation: one slow dependency soaking up every thread and taking down functionality that had nothing to do with it.

A ship's watertight compartments: a hull breach floods one section but the bulkheads keep the rest dry so the ship stays afloat.

Key Concepts

Concretely, instead of letting all outbound calls share one global thread pool, you give each downstream dependency its own bounded pool. If the payment service goes slow and its dedicated pool fills up, calls to payments are rejected or queued, but the pools for search, recommendations, and everything else remain free, so the rest of the application keeps serving. Backpressure is the complementary idea on the input side: rather than accepting unlimited incoming work and collapsing under load, a service signals "I am full" — by rejecting, shedding, or slowing intake — so that overload is bounded and pushed back to the caller rather than absorbed until the service crashes. Bounded queues, semaphores limiting concurrent calls, and load shedding are the everyday tools; reactive frameworks build backpressure into their streaming model.

The insight interviewers want is failure isolation: bulkheads ensure that a problem stays local instead of becoming systemic, which is what lets a system degrade gracefully (some features fail) rather than totally (everything fails). It pairs naturally with circuit breakers and timeouts — the breaker stops calling a broken dependency, the timeout bounds each call, and the bulkhead guarantees that even a flood of slow calls to one dependency cannot starve the others. The cost is some resource fragmentation and tuning, since you must size each pool, but the payoff is that one misbehaving component cannot sink the whole ship.