Retry-After and cursor pagination
The fake server answers 429 once, then 200, and serves three pages of items.
Networks and servers fail in short bursts, so a good client retries only the failures that can pass (timeouts, 429, 5xx), waits longer after each try with random jitter, honours the server's Retry-After header, and never repeats a request that is not safe to repeat.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write backoff_delays(attempts, base, cap) that returns the list of backoff ceilings with no randomness. For (5, 0.5, 4.0) it should be [0.5, 1.0, 2.0, 4.0, 4.0].
Write is_retryable(status) that returns True for 429 and any 5xx except 501, False otherwise.
Write a function wait_time(response, backoff) that returns the larger of the backoff and the Retry-After header (in seconds, if present).
Explain it without notes
Which failures should a client retry, and which should it not?
Explain exponential backoff with jitter and why the jitter is needed.
What is Retry-After, and how does a client use it with its own backoff?
What is idempotency, and how does it affect retrying a POST request?
A POST request to create an order times out. What do you do?
Expected output
first: 429 Retry-After: 3
the server asks us to wait 3.0 seconds (we skip the real sleep here)
second: 200 {'ok': True}
pages: 3 items: [1, 2, 3, 4, 5, 6, 7]