How should a high-throughput service absorb provider 429 responses?

A `429` means 'too many requests' — you've crossed the provider's rate limit. The wrong reaction is to immediately fire the same request again, because that's just one more request against a limit you've already exceeded. The right approach has two sides. First, listen to the provider: a `429` usually comes with a **Retry-After** header telling you exactly how long to wait. Honor it instead of guessing. Second, shape your own traffic so you stop hitting the limit in the first place. A client-side token bucket or a queue lets requests out at a steady rate that stays under the cap, instead of bursting and slamming into it. For the retries you do make, use exponential backoff with jitter so clients don't all retry at the same instant. And when you're near the cap, shed or downgrade low-priority work — defer batch jobs, or route easy queries to a smaller model. The goal is to fit your demand to the available quota, not to push past it.

A `429` is a signal that you're sending faster than the provider's quota allows, so the fix is to shape demand to the quota rather than hammer past it. Start by honoring the provider's own signal. Most `429`s include a **Retry-After** header with the exact wait; respect it instead of guessing a delay. Then prevent the breach proactively. Put a client-side token bucket or a queue in front of the provider so requests leave at a steady rate that stays under the limit. That prevents the bursting that trips it. The token bucket refills at your allowed rate and is the cleanest way to enforce a ceiling. For retries you still need, use exponential backoff with jitter so a fleet of clients that all got `429`d don't retry in lockstep. And when you're near the cap, prioritize. Shed or defer low-value traffic — push batch work to off-peak, route easy queries to a smaller model — so your scarce quota goes to the requests that matter. Blind immediate retries make everything worse. Each retry is another request against an already-exceeded limit, so it deepens the breach. Worse, clients that failed together retry together, synchronizing into a retry storm that keeps the limit pinned and turns a brief throttle into a sustained one.