Topic 11.11
Bulkhead
In one line
Ships have sealed compartments so one leak can't sink the whole ship — same idea for call paths.
Think of it like this
The separate watertight compartments in a ship's hull. If one compartment floods, the walls (bulkheads) stop the water from sinking the entire ship.
Key ideas
- 01
Give each dependency its own thread pool / connection pool budget, so a slow dependency burns ITS budget, not everyone's.
- 02
Without bulkheads: one slow service exhausts the shared pool → ALL services time out (your app down because one partner is slow).
- 03
Implementations: per-scope thread pools (thread-per-dependency), semaphore-based limits, per-dependency connection pools.
- 04
Related: fixed shared pools + queue disciplines (Tomcat maxThreads, OkHttp per-host pools).
- 05
Interview: 'I give payments its own pool of 10 threads and inventory its own 20 — a payment hang can't starve inventory'.
Java / Spring map
- →
Resilience4j Bulkhead (semaphore or thread pool); Tomcat connector limits; per-dependency OkHttp connection pools.
Code & diagrams
Named after a ship's hull: one flooded compartment shouldn't sink the whole vessel.
Explain without notes
Walk the scenario: payments slows 100x. With vs without bulkheads, what happens to inventory calls?
Practice
Size the bulkhead pools (threads, queue) for 3 dependencies with known QPS and p99.
Trade-offs
- ↔
Dedicated pools waste idle capacity when dependencies are healthy — the insurance premium.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
My designs separate dependency budgets so one slow neighbor can't sink the process.