429 Is Not a Ban: Six Rate-Limit Myths I Had to Unlearn

Описание и применение

Разрушение мифов о 429: правильный подход к ограничению запросов повышает эффективность и снижает нагрузку на бесплатные API.

Задача

Developers misinterpret HTTP 429 responses, leading to inefficient retry logic, wasted resources, and degraded performance.

Результат

Adopting correct rate‑limit handling reduced 429 streaks, improved throughput, and prevented unnecessary load on shared free servers.

Рабочий процесс

• 1. Treat 429 as load‑shedding, not a ban.
• 2. Use exponential backoff with full jitter for retries.
• 3. Probe burst and sustained windows separately to understand limits.
• 4. Parse Retry‑After header defensively, falling back to own backoff.
• 5. Run a concurrency staircase probe to find sweet spot.
• 6. Log every rate event (status, headers, elapsed time).

Доказательства

Immediate retries land in the same rate‑limit window. You are not retrying. You are double‑spending your quota.

Источник

Retry‑After is a gift. It is also frequently missing.

Источник