An open-source toolkit called Resilience4J offers various resilience patterns for creating resilient applications. One of the patterns offered by Resilience4J in Java is bulkhead, which restricts the resources used by a failed component in order to stop an application from failing in a cascading fashion. We will go into detail about what it is and how uses it in this article. Check out our Java online classes to learn more.
What is a Bulkhead?
In the event of a hull breach, a physical barrier keeps the various compartments of a ship from flooding. Similar to this, a bulkhead is a pattern used in software architecture that separates resources into discrete areas or pools to stop failures in one pool from impacting the availability of resources in other pools. It can be implemented in various ways, including through the use of network partitions, process pools, and thread pools.
Bulkheads are crucial in a microservices architecture to prevent the system from going offline if one service fails. A bulkhead can stop the failure of one service from affecting other services in the system by isolating services and establishing distinct pools of resources.
Resilience4J in Java Bulkhead
To restrict the number of concurrent requests that a component can process, offers a Bulkhead design. The Java.util.concurrent package’s Semaphore notion is used to implement the Bulkhead pattern. A semaphore is a synchronisation tool that keeps track of a list of permissions that threads can get to access a shared resource.
There are three primary configurations for Resilience4J Bulkhead:
- MaxConcurrentCalls: This configuration determines the most concurrent calls to a protected component that are permitted. The bulkhead will stop accepting further calls when the allotted number is reached.
- MaxWaitDuration: The maximum amount of time that a request must wait before the bulkhead issues a permit is determined by this configuration. A request will be rejected by the bulkhead if the wait time is longer than the set value.
ReserveFactor: The percentage of permits that are set aside for high-priority requests is determined by the ReserveFactor setting. The remaining licences are applied to customary demands.
A strong and resilient application can be made using Bulkhead in conjunction with additional resilience patterns offered by Resilience4J, such as Circuit Breaker and Retry.
Characteristics of the Bulkhead resilience pattern
The Bulkhead resilience pattern offers a number of characteristics to help prevent a cascading failure in an application. Bulkhead has a few significant characteristics, including:
- Concurrency control: To avoid overload and resource depletion, bulkhead restricts the number of concurrent requests that can be made to a component.
- Isolation: Bulkhead separates resources into isolated compartments or pools, ensuring that the availability of resources in one pool is not impacted by failures in another.
- Fault tolerance: Bulkhead helps prevent a failure in one component from cascading to other components in the system, ensuring that the application stays available. It does this by limiting the number of concurrent requests and generating isolated pools of resources.
- Configurability: Bulkhead offers a high level of configuration, enabling programmers to choose the number of concurrent requests allowed, the maximum wait time, and the reserve percentage for urgent requests.
- Ease of use: With only a few lines of code, Resilience4J offers a simple-to-use Bulkhead implementation that can be added to a Spring Boot application.
- Composability: To build a more reliable and resilient application, Bulkhead can be used in conjunction with other Resilience4J resilience patterns like Circuit Breaker and Retry.
Action of the Bulkhead Pattern
Let’s have a look at a straightforward web application that handles user queries. The programme employs a thread pool to handle incoming requests and has a service that handles them.
A thread pool is used by this service to handle requests asynchronously. The thread pool, on the other hand, can get overburdened and start to refuse requests if there are too many, which would result in failure. This error could have an impact on other areas of the system that depend on this service.
We may use this pattern to restrict the number of requests that can be processed concurrently in the thread pool, preventing this failure from having an impact on other areas of the system.
To restrict the number of concurrent requests that can be handled by the thread pool, a semaphore can be added. Only 5 requests can be processed continuously since the semaphore is initialised with a cap of 5 concurrent requests. More than 5 requests will be put in a queue and held there until one of the processing threads is free.
Conclusion
A good pattern for increasing a system’s resilience is the bulkhead pattern. To divide resources and lessen the effects of failures, we can use bulkheads to ensure that failures in one part of the system do not affect other parts of the system. There are numerous other ways that bulkheads can be built, but a good example is to utilise a Semaphore to restrict the number of concurrent requests that can be processed in a thread pool. You can check out our Advanced Java course to learn more about Bulkhead.
