Why is it dangerous to retry every failed request immediately?

Immediate retries from many clients hitting a failing server create a thundering herd, making the problem worse instead of better.

Which HTTP status code indicates you should NEVER retry the request?

400 Bad Request is a client error (4xx) indicating malformed data; retrying the same bad request will always fail.

What is the key difference between a transient error and a permanent error?

Transient errors (like temporary overload) may succeed on retry, while permanent errors (like invalid credentials) will always fail.

You receive a 401 Unauthorized response. What should you do?

401 Unauthorized is a client error (4xx) caused by missing or invalid credentials. Retrying without fixing auth is pointless.

Which HTTP status code suggests the server might recover, making retry worthwhile?

503 Service Unavailable is a server error (5xx) typically temporary; the server may recover and process the retry successfully.

What is the main advantage of exponential backoff over fixed-delay retries?

Exponential backoff increases wait time, giving the server progressively more time to recover between retry attempts.

A server is overloaded and returns 503. If 1,000 clients all retry immediately, what happens?

Immediate retries from many clients cause a thundering herd, overwhelming the recovering server and making the situation worse.

Using the formula wait_time = base × 2^attempt with base=1 second, what is the wait after the 3rd attempt (attempt=3)?

1 × 2^3 = 1 × 8 = 8 seconds. The wait time doubles with each attempt: 1, 2, 4, 8, 16, 32, etc.

If you want waits of 2, 4, 8, 16 seconds for attempts 0–3, what base value should you use?

With base=2: 2×2^0=2, 2×2^1=4, 2×2^2=8, 2×2^3=16. The base multiplies all calculated times.

What issue does exponential backoff solve that fixed-delay retries do not?

Exponential backoff increases wait times, preventing the thundering herd problem and giving servers time to recover.

What is the thundering herd problem?

When many clients fail simultaneously and retry at the same moment, they create a synchronized burst that can crash a recovering server.

500 clients are all using exponential backoff with base=2 seconds. The server crashes at 3:00 PM. What happens at 3:00:02?

Without jitter, all clients calculate the same wait and retry simultaneously, creating a herd burst that re-crashes the server.

What does jitter accomplish in a retry strategy?

Jitter randomizes retry delays so clients do not all retry at the same moment, preventing synchronized load spikes.

Which jitter formula provides the most aggressive spreading of retries?

Full jitter allows any random value from 0 to the cap, spreading retries most widely across the time window.

You use equal jitter with a calculated backoff of 16 seconds. What is the range of possible wait times?

Equal jitter = 16/2 + random(0, 16/2) = 8 + random(0, 8), so range is 8 to 16 seconds.

How does jitter solve the thundering herd problem?

Jitter spreads retry times so clients retry at different moments, avoiding the synchronized burst that crashes recovering servers.

Without a maximum delay cap, what problem can occur with exponential backoff?

Exponential backoff without a cap leads to absurdly long waits (1024s at attempt 10, 32k+ at attempt 15), defeating the purpose.

Why is a maximum attempts cap necessary for retry logic?

Without an attempts cap, retry loops continue forever on permanent failures. A cap ensures we eventually fail and move on.

What is the recommended max attempts range for a user-facing API call?

User-facing API calls typically use 3–4 retries to minimize user-facing latency while handling transient failures.

You are designing retry logic for a background notification job. Which max attempts limit is most appropriate?

Background jobs tolerate longer waits, so 5–7 retries is reasonable to handle transient failures without user-facing impact.

What is a typical maximum delay cap between retries?

A common cap is 30–60 seconds, preventing wait times from growing absurdly while still giving servers recovery time.

Using the formula wait_time = min(max_delay, base × 2^attempt) with base=2 and max_delay=32, what wait time is applied at attempt 5?

2 × 2^5 = 64, which exceeds the cap of 32, so wait_time = min(32, 64) = 32 seconds.

What are the two essential caps needed to prevent unbounded retry loops?

Max attempts prevents infinite retries, and max delay prevents wait times from growing forever. Both are essential.

In a notification system, when should you use exponential backoff with retry?

5xx errors and timeouts are transient; exponential backoff gives the provider time to recover. 4xx errors indicate permanent issues.

You receive a 429 Too Many Requests response when sending notifications. What should you do?

429 responses include a Retry-After header; honoring it is more efficient than your calculated backoff.

After 5 max retry attempts, a notification still fails to send. What should happen?

Move failed notifications to a dead-letter queue and alert engineers so the failure can be investigated and resolved.

How should a notification system handle a 400 Bad Email Address response?

400 is a client error indicating bad data. Retrying is pointless; remove the invalid address and investigate why it was stored.

In an appointment waitlist system, why is time sensitivity important when retrying notifications?

Waitlist systems have time limits; you can only wait so long for a response before offering the slot to the next person.

If a waitlist appointment has a 5-minute deadline for user confirmation, how should you adjust your retry strategy?

With a 5-minute deadline, cap delay at 30 seconds and limit attempts so retries complete before the deadline expires.

Exponential Backoff and Retry — System Design Concept

Q: Which statement best describes what a retry is?

A retry is attempting the same operation again, but critically with timing and error-type checks to avoid making things worse.

🍪 TechCookies

Free

📚Exponential Backoff and RetryFree

16 sections

~29 min total

30 quick quizzes

2 SD challenges linked

0 of 16 done·~30 min left

Concepts›Exponential Backoff and Retry›What Is a Retry?

0 / 16

16 sections~29 min

What Is a Retry?

Retry is attempting the same operation again after failure, with careful timing and conditions.

ReadQuiz

~2 min

⋯

Retry Logic and When NOT to Retry (4xx Errors)

Distinguish transient errors worth retrying from permanent client errors that will fail repeatedly.

ReadQuizCode

~2 min

⋯

What Is Exponential Backoff?

Exponential backoff increases wait time between retries exponentially rather than using fixed delays.

ReadQuizCode

~2 min

⋯

Exponential Backoff Formula

Core formula for calculating retry delays using base and exponential growth by attempt number.

ReadQuiz

~2 min

⋯

The Formula: base × 2^attempt

Standard exponential backoff formula where wait time doubles with each retry attempt.

ReadQuizCode

~2 min

⋯

The Thundering Herd Problem

Synchronized retries from many clients at the same time can overwhelm a recovering server.

ReadQuizCode

~2 min

⋯

What Is Jitter?

Jitter adds randomness to backoff delays to desynchronize retries and prevent herd effects.

ReadQuizCode

~2 min

⋯

Jitter: Solving the Thundering Herd Problem

Jitter distributes retry times randomly to avoid simultaneous request bursts on recovering systems.

ReadQuiz

~2 min

⋯

Why You Need Caps

Without limits, exponential backoff grows unbounded, requiring max attempts and max delay constraints.

ReadQuiz

~2 min

⋯

Max Attempts

Limit the total number of retry attempts (typically 3–7) based on use case criticality.

ReadQuiz

~2 min

⋯

Max Delay Cap

Cap the maximum wait time between retries (typically 30–60 seconds) to prevent excessive delays.

ReadQuizCode

~2 min

⋯

Max Attempts and Max Delay Caps

Both attempt and delay limits are essential to prevent unbounded retries and resource exhaustion.

ReadQuiz

~2 min

⋯

Relevant System Design Questions

Apply retry and backoff patterns to real system design scenarios like notifications and waitlists.

Read

~2 min

⋯

System Design: Notification System

Notifications to external providers require smart retry logic to handle rate limits and transient failures.

ReadQuizCode

~2 min

⋯

System Design: Appointment Waitlist

Waitlist systems must retry notifications within time deadlines while respecting resource constraints.

ReadQuiz

~2 min

⋯

Practice test

30 questions

~10 min

Section 1 of 16ReadQuick quiz

What Is a Retry?

Retry is attempting the same operation again after failure, with careful timing and conditions.

~2 min read

3 quick quizzes

A retry is simply trying the same operation again after it has failed. Imagine you try to send an email and the mail server is temporarily busy. Instead of giving up immediately, you wait a moment and try again. That is a retry.

First attempt → FAIL Wait a bit... Second attempt → FAIL Wait longer... Third attempt → SUCCESS ✓

Simple retries seem obvious, but doing them incorrectly can crash entire systems. The rest of this guide explains how to do them correctly.

☑ Quick check 1/3

Which statement best describes what a retry is?

AAttempting the same operation again after a failure, with appropriate timing

BAlways immediately retrying requests that fail regardless of error type

CAttempting a different operation when the first one fails

DCanceling the request and logging an error instead of trying again

Answer the quiz to continue

Notes

🔍

Loading…