How to Use Circuit Breakers to Decouple Event Retrieval in Microservices

0 Preface

Part 2 discusses the benefits of decoupling event retrieval from event handling; now we explore using a circuit breaker to cope with unavailable request/response APIs.

1 Experience: Using a Circuit Breaker to Pause Event Retrieval

Request/response communication creates tight coupling because both microservices must be available, unlike event‑driven communication where no middleware can intervene when a downstream service is temporarily down. The combination of event loops with request/response retries can increase pressure on an already struggling downstream service, leading to rapid failures and faster event processing, which ultimately harms overall reliability. Applying a circuit breaker addresses this problem.

2 Circuit Breaker

The circuit breaker is a resilience pattern originating from request/response communication that prevents cascading failures caused by retries. Ready‑made components such as resilience4j can be configured alongside HTTP clients.

3.1 Circuit Breaker State Machine

The circuit breaker switches among three states: CLOSED, OPEN, and HALF‑OPEN.

CLOSED: all requests pass through the API; if errors exceed a threshold, the breaker moves to OPEN and returns an error such as NotPermittedException.

After a waiting period, the breaker transitions to HALF‑OPEN, allowing requests again.

If a request succeeds, the breaker returns to CLOSED; if it fails, it reverts to OPEN.

3.2 Integrating a Circuit Breaker into Event‑Driven Microservices

If the circuit breaker is OPEN, API requests fail quickly, but event processing still retries, potentially filling a dead‑letter queue. To avoid this, we pause new event retrieval when the breaker opens, using event listeners that emit a “pause event retrieval” message.

After the wait period, the breaker should become HALF‑OPEN so that requests can pass again. In request/response scenarios, an incoming request can trigger the transition. In event‑driven scenarios, no external request exists, so a scheduled action must trigger the transition and resume event retrieval; otherwise the breaker remains OPEN.

We also recommend setting the event visibility timeout longer than the half‑open wait time; otherwise the same event may be repeatedly retrieved after the transition, eventually ending up in a dead‑letter queue if the API stays unavailable.

Further tuning includes adjusting maxReceiveCount and visibility timeout. For example, with maxReceiveCount=3 and a visibility timeout of 30 seconds, the API can be down for one minute. After that minute, the event is retrieved a third time; if it fails again, it moves to the dead‑letter queue.

3 Conclusion

When integrating event‑driven microservices with request/response APIs, event processing depends on API availability. This article shows how to incorporate a circuit breaker, configure its state machine, pause event retrieval during outages, and fine‑tune timeouts to maintain system resilience.