How Bulkhead Isolation Boosts Microservice Performance with Resilience4j

Introduction

Microservices are essentially distributed systems; unpredictable issues such as network, service, or middleware failures can cascade, so designs must ensure resilience while preventing downstream failures.

Isolation Mode

Like a ship divided by bulkheads, software should split an application into components so that a failure in one does not affect the whole.

For example, service A can handle only 5 concurrent requests and has two endpoints

/a/b

(depends on service B) and

/a

(local).

When 10 concurrent requests hit A, the five calls to

/a/b

block while the five calls to

/a

are also blocked because the whole application’s threads are occupied, leading to poor user experience.

By applying isolation mode and limiting resources per endpoint, e.g., setting a maximum of 2 concurrent threads for

/a/b

, the application retains threads for other requests.

Sample Program

Architecture Diagram

The diagram simulates a simple e‑commerce order flow: user browsing, inventory deduction, and order creation.

User logs in and browses products (inventory module)

Deduct inventory (inventory module)

Create order (order module)

product‑service provides two endpoints:

/products – list all products

/order – call order service to place an order

Code Implementation

<code>├── bulkhead-demo
    ├── order-service        # Order service (8070)
    └── product-service      # Inventory service (8050)</code>

Dependencies: using resilience4j‑spring‑boot2 (v1.6.1) instead of Hystrix.

<code>&lt;dependency&gt;
    &lt;groupId&gt;io.github.resilience4j&lt;/groupId&gt;
    &lt;artifactId&gt;resilience4j-spring-boot2&lt;/artifactId&gt;
    &lt;version&gt;1.6.1&lt;/version&gt;
&lt;/dependency&gt;</code>

Configure bulkhead limits in application.yml.

<code>server:
  tomcat:
    threads:
      max: 5   # limit total concurrent threads for testing
resilience4j.bulkhead:
  instances:
    createOrder:
      maxConcurrentCalls: 2   # limit this endpoint to two concurrent calls</code>

product‑service controller.

<code>@SneakyThrows
@GetMapping("/order")
public String buy() {
    orderService.createOrder().get();
    return "success";
}

@SneakyThrows
@GetMapping("/products")
public String products() {
    Thread.sleep(100);
    return "products";
}</code>

Remote call wrapped with Bulkhead.

<code>@Bulkhead(name = "createOrder", fallbackMethod = "getError")
public CompletableFuture<String> createOrder() {
    return CompletableFuture.supplyAsync(() ->
        restTemplate.getForEntity("http://localhost:8070/createOrder", String.class).getBody());
}
public CompletableFuture<String> getError(Throwable error) {
    log.warn("Create order failed {}", error.getMessage());
    return CompletableFuture.completedFuture("");
}</code>

order‑service implementation.

<code>@RestController
public class PayController {
    @SneakyThrows
    @GetMapping("/pay")
    public String pay() {
        Thread.sleep(10000); // simulate payment delay
        return "支付成功";
    }
}</code>

Testing

JMeter: 10 threads call /order, 10 threads call /products for 30 s.

With Resource Isolation

30 s produced 1 750 samples, throughput 43.5 requests/s.

Without Resource Isolation

30 s produced 50 samples, throughput 49.8 requests/min.

Conclusion

When application resources are constrained, setting bulkhead isolation dramatically improves overall performance. Resource contention occurs when concurrent requests exceed the container’s capacity; the test limited Tomcat to 5 concurrent threads while generating 20 concurrent requests.

Source code: https://github.com/lltx/microservices-pattern

References and some images: https://www.vinsguru.com