Spring / Spring Retry Interview Questions
What is exponential backoff with jitter and why is it preferred over plain exponential backoff?
Exponential backoff increases the delay between retries by multiplying the previous delay by a factor (e.g., 2). While this prevents relentless hammering, it creates a new problem in high-concurrency systems: all clients that started failing at the same time will retry at exactly the same intervals — 1s, 2s, 4s, 8s — causing synchronized waves of load on the recovering service, known as the thundering herd problem.
Jitter adds randomization to the delay, spreading retries across a time window and breaking the synchronization.
Without jitter (synchronized retries):
// 100 clients all retry at exactly t=1s, t=2s, t=4s, t=8s
With jitter (spread retries):
// Client 1 retries at t=0.7s, t=1.9s, t=3.2s // Client 2 retries at t=1.2s, t=2.7s, t=4.8s // Retries are spread across the window
In Spring Retry, jitter is enabled via:
@Backoff(delay = 500, multiplier = 2, maxDelay = 8000, random = true)
Or programmatically:
ExponentialRandomBackOffPolicy backOff = new ExponentialRandomBackOffPolicy(); backOff.setInitialInterval(500); backOff.setMultiplier(2); backOff.setMaxInterval(8000);
AWS recommends exponential backoff with full jitter as the default retry strategy for most distributed systems because it results in the best overall system throughput during recovery events.
More Related questions...
