Making retries safe: idempotency keys, backoff, and dead-letter queues
Networks fail in the middle of requests, so real systems retry, and retries are where duplicate charges and lost messages come from. Learn the difference between at-least-once, at-most-once, and 'exactly-once' delivery, and why the last one can't exist over a lossy network. You'll also cover idempotency keys and server-side dedup, exponential backoff with jitter, which requests are safe to retry, the Two Generals' Problem, and poison messages, plus how to retry a payment without charging the customer twice.
Questions
- Not answered. Which delivery guarantee does this broker behavior describe?
- Not answered. Which design delivers the achievable version of 'exactly-once'?
- Not answered. What does the Two Generals' Problem establish?
- Not answered. Which HTTP methods are idempotent?
- Not answered. What should the server do when the same idempotency key arrives again?
- Not answered. Which statements about a correct idempotency-key design are true?
- Not answered. How many seconds does the client spend waiting in total?
- Not answered. Why add jitter to backoff?
- Not answered. What sleep time does full jitter use instead of the baseline?
- Not answered. Which request is safe to retry blindly?
- Not answered. What's the most likely outcome of retrying 30 hours later?
- Not answered. What is the queue for repeatedly-failing messages called?