Rate limits as a budget, not an error condition

Most retail code treats a rate limit as something that happens to you. It's more useful to treat it as a budget you're spending. The mental model that helped: you have a bucket that refills at a fixed rate and every request takes a token. Bursting is fine as long as the bucket has tokens. Sustained demand above the refill rate empties it, and then you're queued or rejected regardless of how urgent the request is. Which reframes the design question. Instead of "how do I handle the error," it becomes "what am I spending my tokens on, and is that the highest-value use." Polling something every second that changes every minute is spending sixty tokens to learn one thing. I went through my own request pattern with that lens and found most of my budget was going to a status endpoint I was polling far more often than the status could possibly change. Cutting that freed up enough headroom that the limits stopped being a factor entirely.