The bulkhead pattern divides a system into isolated compartments, each with its own limited resources such as threads, connections, or processes. The name comes from ship hulls, where watertight partitions stop one breach from sinking the whole vessel.
Why it matters
Shared resources spread failure. If every feature draws from the same pool of 100 worker threads, one slow dependency can occupy all of them and starve healthy endpoints. Bulkheads cap the damage, so the checkout still works while the report generator struggles. It reduces blast radius.
Example
An app calls two external services. Instead of one shared pool, you configure:
payments client: max 20 concurrent calls
shipping client: max 10 concurrent calls
reports client: max 5 concurrent calls
If the shipping API hangs, at most 10 workers are stuck waiting, and payments is untouched. Calls over the cap fail immediately or queue briefly. The same idea applies at larger scale: separate database replicas for analytics and customer traffic, or dedicated clusters for premium customers.
Bulkheads pair naturally with a circuit breaker.
Common mistakes
- Sizing compartments by guesswork rather than measured traffic.
- Isolating threads but sharing the same database, so the bottleneck simply moves.
- Making pools so small that normal bursts are rejected.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.