Handle HTTP 429 without creating a retry storm

HTTP 429 tells the client to reduce request pressure. Retrying every failed quote immediately can multiply the problem across browser tabs and backend workers.

RFC 6585 defines the status and allows a Retry-After indication. Parse the provider's documented response, respect a valid delay and apply a bounded fallback when it is absent. Plan quotas belong in configuration, not hardcoded assumptions copied from an old pricing page.

Coordinate at the actual bottleneck

If a provider limit applies to a shared credential, independent per-browser retry loops cannot enforce it. Put a scheduler or token budget where the credential is used. Collapse identical indicative requests where appropriate, cancel superseded work and give execution-critical checks a deliberate priority policy.

Add randomized delay to eligible retries so many workers do not resume together. Bound attempts and total elapsed time. A quote that becomes stale while waiting should be refreshed from current inputs rather than submitted merely because the retry eventually succeeds.

Distinguish operations

A read-only price request can often be retried safely. A signed-order submission has an unknown outcome after transport failure and needs idempotency or status reconciliation. HTTP method semantics are a starting point, but the provider's application contract determines the final retry policy.

Expose throttling as a temporary service condition, not as insufficient token liquidity. Track 429 counts, queue time and abandoned requests separately from no-route results.

A useful load fixture sends concurrent requests under one synthetic credential, injects Retry-After and verifies that total upstream traffic falls. Confirm that changing the trade input removes old queued work instead of executing it later.