Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
Why does adding random "jitter" to a retry delay matter, beyond exponential backoff alone?
💻 Code Challenge | +75 XP
Write a retryWithBackoff function that classifies errors as retryable or not (retrying only 429 and 5xx status codes), applies exponential backoff with jitter, and enforces both a max attempt count and a max total elapsed time budget.
A downstream service outage caused thousands of clients to all retry simultaneously using fixed exponential backoff, creating a synchronized traffic spike that prolonged the outage. Reorder the steps to fix this using jitter.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant
Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Retrying every caught error indiscriminately, without checking whether it's actually a transient, retryable failure
// Wrong: retries EVERY error, including ones that will never succeed
try { await chargeCard(amount); } catch { await retry(); }
// Correct: only retries genuinely transient failures
catch (err) { if (isRetryable(err)) await retry(); else throw err; }The Solution //
Retrying an error caused by invalid input or a genuine business rule violation (like an expired credit card) wastes time and resources attempting something that will fail identically on every retry, and can delay surfacing a real problem that needed immediate attention instead of silent repeated retries. Explicitly classify which errors are worth retrying before attempting to retry at all.
The Error //
Retrying a non-idempotent operation (like a payment charge) without an idempotency mechanism
// Dangerous: could double-charge if the first attempt actually succeeded
await chargeCard(amount);
// Correct: safe even if retried, downstream recognizes the duplicate
await chargeCard(amount, { idempotencyKey: orderId });The Solution //
If the original request actually succeeded but its response was lost (a network blip affecting only the return path), a naive retry re-executes the operation, potentially duplicating a real side effect like a payment charge. Use an idempotency key so the downstream system can recognize and safely ignore a duplicate retry of an already-completed operation.