Idempotency, Retries & Delivery Guarantees
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
- 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?