Rate Limiter (Time-based): A client can make 100 requests in a minute. Assume you have a fleet of automated clients or “boats” doing ping tests. If we don’t set a limit, they can spam the system with infinite requests and absolutely kill the servers. Rate limiting throttles them based on a clock.
Bulkhead (Concurrency-based): Bulkhead counts the number of active, in-flight calls made to a downstream service. It cares about how many calls are currently processing and waiting for a response. Assume a developer accidentally creates an infinite loop that calls a downstream service across multiple threads simultaneously. Without a bulkhead, your resources get completely exhausted, and your service is gone.
Basic Settings for Bulkhead:
Resilience4j:
Bulkhead:
fastMethodBulkhead:
type: SEMAPHORE or Thread
maxConcurrentCalls: 10 // number of calls can make
maxWaitDuration: 500ms // max time it can wait before failing.
queueCapacity: 10 // number of threads can wait in the queue.
keepAliveDuration 10s. //They can wait in the waiting queue.
fastMethodBulkhead:
type: THREADPOOL
max-concurrent-calls: 20
max-wait-duration: 200ms
queueCapacity: 10
keepAliveDuration 10s
@Bulkhead(name = “fastMethodBulkhead”, type = Bulkhead.Type.SEMAPHORE)
public String getQuickReview(String hotelId) {
return quickClient.getReviews(hotelId);
}
// Long-running method - fewer concurrent threads
@Bulkhead(name = “longMethodBulkhead”, type = Bulkhead.Type.THREADPOOL)
public String getFullReview(String hotelId) {
return slowClient.getDetailedReviews(hotelId);
}
We can override the bulkhead at method level using the service name, all methods need not to follow the same timings.
When bulkhead rejects the request, it is fail-fast and throws a BulkheadFullException.
Semaphore Vs ThreadPool
- Semaphore is counter based, based on the count it will allow concurrent threads. use the caller/main thread to update the counter. faster compare to thread pool.
- Thread Pool use a separate thread to tract the count and executed asynchronously
Top comments (0)