How do I design retries and dead-letter handling?
Understand the concept
Retries repeat failed work in the hope that a temporary problem has passed. Backoff spreads attempts over time, jitter avoids synchronized retry bursts, and a dead-letter queue stores work that exceeded its retry policy. Without limits, retries can turn a small outage into sustained overload.
Important ideas
-
Retry temporary failures with exponential backoff, random jitter and a limit.
-
Respect provider rate limits; avoid retrying permanent validation failures.
-
Send repeatedly failing messages to a dead-letter queue for investigation and controlled replay.
-
A timeout after sending an external request means the result may be unknown, not that the external action definitely failed.
Can you explain it without the notes?
How do I design retries and dead-letter handling?
Use your own words. Explain an example and one limitation before checking the explanation.
Check your explanation
Retries repeat failed work in the hope that a temporary problem has passed. Backoff spreads attempts over time, jitter avoids synchronized retry bursts, and a dead-letter queue stores work that exceeded its retry policy. Without limits, retries can turn a small outage into sustained overload.
Turn this concept into a clear answer.
- Classify failures as permanent, temporary or uncertain before deciding whether and how to retry.
Adapted from 07_SYSTEM_DESIGN_ARCHITECTURE.md · “How do I design retries and dead-letter handling?”. Examples are study fragments; framework behavior can depend on your version.