A strategy where failed operations are retried after progressively longer wait times, often with some randomness.
In distributed systems and networked applications, temporary failures (like timeouts or rate limits) are common. Instead of retrying immediately, exponential backoff spaces out retries to avoid overwhelming the system and to allow recovery time.
Use it when interacting with unreliable or rate-limited services to reduce load and increase the chance of success.
You need to know
Exponential Delay: After each failure, the wait time increases exponentially (e.g., 1s, 2s, 4s, 8s...), typically up to a maximum cap.
Jitter: Adding randomness (jitter) to backoff times helps avoid "thundering herd" problems when many clients retry at once.
Retry Limits: Always cap the number of retries or the total wait time to avoid infinite loops.
Popular technologies
AWS SDKs – Built-in exponential backoff and jitter for handling throttled requests.
Google Cloud Client Libraries – Implement backoff with jitter as a standard practice for error handling.
gRPC – Supports configurable retry policies with exponential backoff.
Like posts like this?
Every week, you'll get a new system design concept, broken down like this one.
Free subscribers also get a little bonus:
🎁 The System Design Interview Preparation Cheat Sheet
If you're into visuals, paid subscribers unlock:
→ My Excalidraw system design template – so you have somewhere to start
→ My Excalidraw component library – used in the diagram of this issue
No pressure though. Your support helps me keep writing, and I appreciate it more than you know ❤️