Back to the Catalog
system-design
http

Idempotency, Retries & Delivery Guarantees

12 questions

Networks fail mid-request, so real systems retry — and retries are where correctness quietly breaks. Build intuition for at-least-once vs. at-most-once vs. 'exactly-once' (and why the last is a myth), idempotency keys and server-side dedup, exponential backoff with jitter, safe vs. unsafe retries, the Two Generals' Problem, and poison messages — including how to make a payment survive a duplicate without double-charging.

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?