Patterns

Bulkhead

Give each dependency or customer its own pool of capacity, so one failing part cannot drain the resources every other part needs.

A bulkhead splits shared capacity into separate compartments, like the walls inside a ship's hull.

Use it when#

  • One pool of threads, connections or workers serves several dependencies.

  • A slow dependency can use up that whole pool.

  • One tenant or one kind of traffic can crowd out the rest.

How it works#

Each dependency gets its own limit. A service with 100 worker threads might give 30 to the search call, 30 to payments and 40 to everything else. When search turns slow, its 30 threads fill and further search calls fail fast, while the 70 other threads keep serving pages. Without the split, search takes all 100 and the whole service stops, though only one feature was broken.

The same idea works at any size: separate connection pools, separate queues, separate deployments per customer tier, or separate cells that each serve a slice of users.

What it costs#

Walls waste capacity. A compartment can sit idle while its neighbor is full, so the total you need grows. The limits also need tuning, because a compartment sized too small rejects work that the system could have handled. Start with the dependencies most likely to hang.

In Quorum#

Drag to pan. Hold Ctrl or Cmd and scroll to zoom.

At 4.00k Users the Simulation solves this Design to Apdex 1.00, p99 274 ms, 0.0% errors and $7.04/s Burn. A bulkhead acts only while search is slow, so a steady-state solve looks the same with or without it.
WhereSettingValueWhy
App ServerInstance sizelargeOne App Server with one pool of slots serves every dependency, which is what a bulkhead protects.
DatabaseInstance sizemediumSized so the Database is not the weak part.
Search EngineInstance sizemicroThe smallest Search Engine is the dependency most likely to slow down.
Link App Server → Search EngineBulkheadOnA call to search may hold the caller for only a short fixed time, so a slow search cannot keep every slot.

Research this Design needs: Full-text search, Object storage, Timeouts and retries, Backoff with jitter, Circuit breakers, Bulkheads.

A bulkhead is a setting on a Link, not on the App Server. It stops one call from holding its caller's slot for longer than a short fixed time, so a slow Search Engine fails its own calls and frees the slot for the Database and Storage calls. The Link into search carries it, and the other Links keep their normal wait. Search is healthy at the solved load, so the caption matches the same Design without the bulkhead. Bulkheads unlocks it and needs Circuit breakers.

The game's bulkhead limits how long a dependency may hold a slot, which is the same compartment idea applied to time. The Connection Pooler guards a shared pool in a related way. The glossary defines bulkhead and blast radius.