Key takeaways
- Rate limits control request pace or concurrency, while credits and total quotas control different budgets.
- The limit may be shared across keys, workers or endpoints.
- Retry only eligible operations with bounded delay and respect the service’s guidance.
Overview
Limits may apply per account, key, endpoint, IP address or resource. A requests-per-minute allowance differs from a concurrency limit or a credit balance. HTTP 429 commonly indicates too many requests, and a response may include retry guidance. Clients should respect documented limits, coordinate across workers and avoid synchronized retry storms.
How it works
Read the scope and units of the service’s limits.
Throttle shared workers and inspect response headers or error details.
Retry eligible requests with bounded backoff and jitter, honoring server guidance.
Read the scope and units of the limit
A service may limit requests per minute, simultaneous jobs or expensive operations within a separate budget. The scope can be an account, API key, endpoint or resource. Five workers using one account do not necessarily receive five independent allowances. Identify the shared boundary before deciding how much work to run concurrently.
Keep pacing limits separate from credit exhaustion and authorization failures. Waiting can resolve a temporary request-rate limit but will not necessarily add credits or restore an expired credential. Inspect the service’s error code and response details instead of sending every unsuccessful request through the same retry loop.
| Limit type | What it constrains | Possible client response |
|---|---|---|
| Request rate | Operations within a time window | Throttle and honor retry guidance |
| Concurrency | Operations running at once | Queue work until capacity is available |
| Usage quota | Total allowed usage in a period | Pause and surface the quota state |
| Credit balance | Available paid or allocated consumption | Stop or request the authorized budget change |
Coordinate workers and avoid retry storms
HTTP 429 indicates too many requests and may include Retry-After guidance. Honor the provider’s documented response semantics, then use bounded backoff and jitter where appropriate. Jitter spreads retries so many workers do not wake at exactly the same moment and create another burst.
Use a shared queue or limiter when the allowance is shared. A local limiter in each worker can still exceed the account total. Track in-flight operations and cancellation so a stopped user job does not continue occupying capacity or consuming credits. Retrying also requires idempotency or another safe recovery strategy for operations with side effects.
Source material: MDN — HTTP 429: Too Many Requests ↓
Estimate completion time with the actual bottleneck
An illustrative job contains 600 independent requests under a sustained allowance of 60 requests per minute. Ten minutes is a theoretical pacing minimum before latency, failures, shared traffic and other constraints. Adding workers cannot beat the same shared rate limit; it may only increase contention.
Measure queue time, service time, throttled requests and exhausted retries separately. If the queue grows while service latency is stable, the limit may be the bottleneck. If requests are slow despite unused rate capacity, investigate concurrency or service performance. Explain the job’s waiting state to users rather than making a healthy queue look like a frozen application.
What this looks like in practice
Five workers share one account limit. A central queue spaces their requests, and a 429 response pauses eligible work rather than causing each worker to retry immediately.
Examples explain the concept; they are not reported customer results.What to check
Test burst behavior, shared-account usage and retry exhaustion. Track queue time and error rate separately from the cost of successful calls.
Common mistake
Treating a rate limit as a transient error to retry without delay, making the overload worse and potentially exhausting the job’s retry budget.
Rate limiting vs. Idempotency
Rate limiting controls when and how often requests occur. Idempotency controls the effect of repeating an operation. A reliable retry strategy often needs both.
Read the Idempotency definition →Questions answered
What is Rate limiting?
Rate limiting controls how many requests or operations a caller may perform within a period or concurrency budget, protecting service capacity and enforcing fair or contracted usage.
Is a rate limit the same as running out of credits?
No. Rate limits constrain request pace or concurrency. Credits or quotas may constrain total paid usage. Inspect the service’s error code before deciding what to do.
Should every 429 be retried?
Only when the operation is safe to retry and the job remains within its deadline and budget. Follow the service’s guidance and stop after bounded attempts.
Should an application retry every rate-limited request?
Only if the operation is safe to retry and remains within the job’s deadline and budget. Follow the provider’s guidance and stop after bounded attempts. Some limits require a configuration or quota change rather than a short delay, so classify the specific response first.
Does increasing concurrency always increase throughput?
No. A shared rate limit, downstream capacity or contention can cap throughput. More workers may produce more rejected requests without finishing sooner. Measure the bottleneck and coordinate the shared allowance before changing concurrency.
References and further reading
Primary documentation and source material for this topic. Sources checked September 14, 2026; provider requirements can change.
Continue reading on the blog
Explore all articles and guides →Put the concept to work.
Explore the relevant AstroFabric workflow and see how the pieces connect.
Help keep this guide useful. Suggest a correction or browse the full glossary.