Back to the catalog

Making retries safe: idempotency keys, backoff, and dead-letter queues

12 questions

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

  1. Not answered. Which delivery guarantee does this broker behavior describe?
  2. Not answered. Which design delivers the achievable version of 'exactly-once'?
  3. Not answered. What does the Two Generals' Problem establish?
  4. Not answered. Which HTTP methods are idempotent?
  5. Not answered. What should the server do when the same idempotency key arrives again?
  6. Not answered. Which statements about a correct idempotency-key design are true?
  7. Not answered. How many seconds does the client spend waiting in total?
  8. Not answered. Why add jitter to backoff?
  9. Not answered. What sleep time does full jitter use instead of the baseline?
  10. Not answered. Which request is safe to retry blindly?
  11. Not answered. What's the most likely outcome of retrying 30 hours later?
  12. Not answered. What is the queue for repeatedly-failing messages called?