Exercise 2: Why Retrying Without Backoff Makes Throttling Worse — Possible Solution ==================================================================== WHAT IMMEDIATE RETRYING DOES ------------------------------ Per this chapter's warn-box, "a client that immediately retries the instant it receives a 429, without waiting, adds more load exactly when the server just asked it to slow down." Each retry is itself another request counted against the same rate limit, sent at the exact moment the server has signaled it wants less traffic, not more. WHY THIS COMPOUNDS RATHER THAN RESOLVES THE PROBLEM ------------------------------ Since the limit hasn't reset yet (that's why the 429 happened in the first place), an immediate retry is very likely to be rejected too - producing another 429, which, if the client keeps retrying immediately again, produces another, and so on. Instead of waiting out a brief window and then succeeding, the client generates a rapid, repeating stream of requests and rejections. WHY THIS TURNS A BRIEF THROTTLE INTO A SUSTAINED PROBLEM ------------------------------ Per this chapter, this "can turn a brief, legitimate throttle into a sustained, self-inflicted problem." What should have been a short, temporary rejection followed by a successful retry after the window resets instead becomes an ongoing cycle of failed requests, as long as the client keeps retrying faster than the limit actually clears - extending the disruption well past what the original limit would have caused on its own. WHAT A WELL-BEHAVED CLIENT DOES INSTEAD ------------------------------ Per this chapter, "a well-behaved client respects the Retry-After header directly... rather than guessing at its own retry timing." Using the server's own stated reset time ensures the retry only happens once the limit has actually cleared, avoiding the compounding effect entirely. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains the specific mechanism by which immediate retries add load at the worst possible moment, why that compounds into a sustained problem rather than a brief one, and names the correct behavior (respecting Retry-After) as the fix.