This pattern is named bulkhead because it behaves as the partition of a ship to prevent the ship from sinking. It basically isolates the various compartments of a ship to avoid or minimize the risk of sinking.

The same applies to software, where one failure does not compromise the entire system. In IT, specifically when implementing a data access layer, the bulkhead pattern should be used for connection pools. Either a database, or HTTP connections that have one single connection pool, could compromise the entire system. Suppose your code does not release connections properly—the connection pool would be full of active connections very quickly, and in that case, services dealing with databases or other services via HTTP connections will not be able to function properly, even if they have to deal with different resources.

The following image depicts various applications relying on the same connection pool. All of a sudden, a bug in one application saturates the connection pool. The consequence is that the connections in the pool are all locked by one application, and the other applications cannot use it:

Instead, by creating a connection pool for each service, it avoids entire system failing  with failure instead, compromising just one functionality, as illustrated in the following diagram:

In our football manager application, we dedicated pools for each service, and we also used a different database for each service to actually show that you can rely on different tools for the right job—homogeneity is not mandatory anymore with microservices and with a PaaS providing heterogeneous runtime.

The bulkhead pattern is surely a good approach, but sometimes your system still needs to provide some kind of minimum capability for that functionality. In that case, the circuit breaker is the pattern you need.