One shared thread pool serves all three providers. Make Flight slow and watch blocked requests fill the pool until Train and Bus starve — a cascading failure. Flip on bulkheads (a pool per provider) and the flight failure stays contained while everything else keeps flowing.
All three providers draw from one thread pool. The flight provider is slow (its requests hold threads for ages). Watch it fill the pool and starve train & bus — then flip on bulkheads and isolate the damage.
Shared pool (12 threads)
✈️ Flight
✓ 0 served
✗ 0 blocked
🚆 Train
✓ 0 served
✗ 0 blocked
🚌 Bus
✓ 0 served
✗ 0 blocked
Cascading failure: slow flight requests hog the shared pool, so train & bus can't get a thread and start failing — one bad provider takes the whole system down.
What just happened
▹When services share one resource pool (threads, connections, workers), a single slow dependency can hold every resource — and starve the healthy services. That's a cascading failure: one provider's problem becomes everyone's outage.
▹The bulkhead pattern isolates resources: give each dependency its own pool. A slow flight provider can only exhaust its own threads; train and bus keep their pools and keep serving.
▹Named after a ship's watertight compartments — flood one, the ship still floats. You trade some peak efficiency (idle threads can't be borrowed) for the guarantee that one failure can't sink everything.