5 exercises on retry and exponential backoff vocabulary.
0 / 5 completed
1 / 5
What is exponential backoff in retry logic?
Exponential backoff: each successive retry waits longer (1s, 2s, 4s…). If many clients retry immediately, they can hammer a recovering service back down. Backing off reduces this thundering herd effect and allows the service time to recover.
2 / 5
Why is jitter added to exponential backoff?
Jitter: without randomness, clients with identical backoff schedules all retry at the same second — creating synchronized bursts (thundering herd). Adding random jitter desynchronizes retries, smoothing load on the target service.
3 / 5
What is the difference between a transient fault and a permanent error for retry policy?
Transient vs permanent: retrying a 400 (malformed request) wastes time — the result will always be the same. Retry policies should only retry on transient status codes (429, 503, connection timeouts) where the outcome may differ.
4 / 5
What is a retry budget?
Retry budget: if every service retries every call three times, a partial outage can multiply traffic by 4×, making recovery harder. A retry budget limits the total retry rate across a service, preventing retry storms from amplifying the original failure.
5 / 5
What is idempotency's relationship to retries?
Idempotency and retries: retrying a non-idempotent operation (create order, charge payment) can result in duplicate records or double charges. Operations must either be made idempotent (using idempotency keys) or explicitly excluded from retry logic.