Bulkhead Pattern
The bulkhead pattern splits shared resources into separate pools. Trouble in one pool cannot consume every slot needed by the others.
critical pool + optional pool + per-pool limit + queue + saturation signalcritical pool + optional pool + per-pool limit + queue + saturation signalSREAnother example
Thumbnail work fills its four connection slots. Checkout has eight separate slots, so orders still finish while thumbnails wait.
Main parts
- 01Failure boundary
- 02Critical pool
- 03Optional pool
- 04Per-pool limit
- 05Separate queue
- 06Saturation signal
Use it when
Use separate pools when critical and optional work share threads, connections, queues, or instances. Size and monitor every pool.
Do not use it when
Do not split resources without a real failure boundary. Too many small pools can waste capacity and hide overload.
Name used in code
critical pool + optional pool + per-pool limit + queue + saturation signal Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Bulkhead Pattern for this system while keeping data correct, secure, and easy to operate. User context: Thumbnail work fills its four connection slots. Checkout has eight separate slots, so orders still finish while thumbnails wait. Technical concept or control: Bulkhead Pattern. Why it fits: Use separate pools when critical and optional work share threads, connections, queues, or instances. Size and monitor every pool. Do not use it when: Do not split resources without a real failure boundary. Too many small pools can waste capacity and hide overload. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Bulkhead Pattern. Definition: The bulkhead pattern splits shared resources into separate pools. Trouble in one pool cannot consume every slot needed by the others. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.