The bulkhead pattern partitions scarce resources between functions or customer groups. When one dependency slows down, its requests occupy their own connection pool, worker pool or queue. Other pools can continue to serve traffic. Business requirements and failure scenarios determine the boundary, not the name of a microservice.
Fictional example: orders and reports call different services but share a pool of 40 connections. A slow reporting service occupies the pool and blocks orders. Separate concurrency limits and a bounded reporting queue keep the critical path available, at the cost of delayed reports.
How do you decide?
- Identify the functions that must continue when another dependency fails.
- Measure load, response times, pool saturation and queue length for each function.
- Choose separate limits, timeouts and overload behaviour. Test a slowdown under representative traffic.
Trade-off: separate pools can leave capacity unused and add operational parameters. Choose isolation boundaries according to the cost of failure.
Discuss this article
Share a constructive observation or an anonymised example. Comments are checked by AI before publication. Uncertain cases go to the moderator.