Bulkhead Isolation

1. What exactly is Bulkhead Isolation?

Your ASP.NET Core API calls three separate external services during a single request, a payment provider, a notification provider, and a maps provider. All three calls share one HttpClient, with a single pool of outbound connections.

Now the maps provider slows down during an outage. Requests to it hold onto connections far longer than usual, and the shared pool fills up with maps requests. Calls to the other two, perfectly healthy, services start failing too, simply because there are no connections left for them.

One dependency's trouble uses up the shared capacity every other dependency also needed. That's exactly what the Bulkhead Isolation pattern prevents.

2. How would you fix it in .NET?

Bulkhead isolation walls each dependency off: give each one its own separate, limited pool of connections instead of one shared pool for all of them. In .NET, configure a named HttpClient per dependency via IHttpClientFactory, each with its own connection limit, so a slow or failing dependency can now only ever exhaust its own pool, never anyone else's.

Use: IHttpClientFactory (AddHttpClient)

Partition shared resources per dependency, so one dependency's trouble stays that dependency's problem.

3. How can you visualize it in everyday terms?

A ship is built with watertight bulkheads dividing it into separate compartments. If one compartment floods, the water stays sealed inside it.

Without those walls, water flooding into one section would spread through the whole hull, and a single puncture could sink the entire ship.

Wall off each dependency's resources the same way a ship walls off its compartments.