Bulkhead design pattern

Separate out different services in the microservices application into various pools such that if one of the services fails, the others will continue to function irrespective of failure. Create a different pool for each microservice to minimize the impact:

• Problem: This pattern takes inspiration from sectioned out parts of a ship's hull. If the hull of a ship is damaged, then only the damaged section would fill with water, which would prevent the ship from sinking. Let's say you are connecting to various microservices that are using a common thread pool. If one of the services starts showing delay, then all pool members will be too exhausted to wait for responses. Incrementally, a large number of requests coming from one service would deplete available resources. That's where this pattern suggests a dedicated pool for every single service.
• Solution: Separate service instances into different groups based on load and network usage. This allows you to isolate system failures and prevent depletion of resources in the connection pool. The essential advantages of this system are the prevention of propagating failures and ability to configure capacity of the resource pool. For higher priority services, you may assign higher pools.

For example, given is a sample file from which we can see pool allocation for service shopping-management: https://gist.github.com/parthghiya/be80246cc5792f796760a0d43af935db.

• Take care of: Make sure to take care of the following points to make sure that a proper bulkhead design is implemented:
• Define proper independent partitions in the application based on business and technical requirements.
• Bulkheads can be introduced in forms of thread pools and processes. Decide which one is suitable for your application.
• Isolation in the deployment of your microservices.

• When to use: The bulkhead pattern adds an advantage in the following scenarios:
• The application is huge and you want to protect it from cascading or spreading failures
• You can isolate critical services from standard services and you can allocate separate pools for them

• When not to use: This pattern is not advisable for the following scenarios:
• When you don't have that much budget for maintaining separate overheads in terms of cost and management
• The added level of complexity of maintaining separate pools is not necessary
• Your resources usage is unexpected and you can't isolate your tenants and keep a limit on it as it is not acceptable when you would place several tenants in one partition