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

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

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

<dependency>
    <groupId>io.github.resilience4j</groupId>
    <artifactId>resilience4j-spring-boot2</artifactId>
    <version>1.6.1</version>
</dependency>

Configure bulkhead limits in application.yml.

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

product‑service controller.

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

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

Remote call wrapped with Bulkhead.

@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("");
}

order‑service implementation.

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

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