How to Implement Rate Limiting in Event‑Driven Microservices with Resilience4j

Introduction

Part 3 covered circuit‑breaker handling for unavailable request/response APIs. This final article in the series focuses on rate limiting as a complementary technique to ensure microservices respect upstream API traffic caps (e.g., 100 requests per second).

Rate Limiting Event Handling

External services often enforce strict request rates. Without protection, an event‑driven microservice can exceed these limits, triggering HTTP 429 Too Many Requests responses. A rate limiter—commonly implemented with a token‑bucket algorithm—prevents excess calls by allowing an event to proceed only when a token is available.

When a token is unavailable, the event processing is paused until the bucket refills, avoiding repeated 429 errors and reducing the need for circuit‑breaker retries that would otherwise flood a dead‑letter queue.

If the bucket contains tokens, one token is consumed and processing continues.

If no token is available, processing is delayed until a new token arrives.

Integrating the Rate Limiter into Event Processing

The blockAndAcquireToken() method embodies this behavior: it attempts to take a token, blocks the thread until a token becomes available (or a configured timeout expires), and then proceeds to create and send the request.

void processEvent(Event event) {
    // ...
    rateLimiter.blockAndAcquireToken();
    Request request = createRequest(event);
    Response response = sendRequestAndWaitForResponse(request);
    moreBusinessLogic(event, response);
    // ...
}

In Resilience4j, blockAndAcquireToken() will wait only up to the configured timeout; if no token is obtained, it returns an error, causing the event to fail rather than be retried endlessly. Properly aligning the visibility timeout with the rate‑limiter wait time prevents duplicate processing.

Conclusion

Rate limiting is an effective solution for complying with upstream API traffic restrictions in event‑driven microservices. Combined with circuit‑breaker patterns, it helps avoid overload, reduces unnecessary retries, and ensures stable integration with third‑party services.