Resources · 77
API quotas: bound load and recover without a retry storm
Define budgets, counting identities and recovery behavior when a client reaches a limit.
· 2 min
What this guide helps achieve
- Define the limited resource
- Define overload behavior
- Bound recovery
- Exercise saturation and restoration
Quick check
- Is HTTP 429 sufficient protection?
- Is Retry-After always a number?
- Can every request be retried automatically?
Step-by-step method
- 01
Define the limited resource
Separate request counts, transferred volume, compute cost and concurrent operations. Choose a counting identity and scope: client, account, route or service. Shared IP addresses can group independent people; per-user API keys alone cannot constrain aggregate cost.
Deliverable: unit, window and scope for each limit.
- 02
Define overload behavior
Specify rejection, queuing or reduced service. HTTP 429 describes too many requests; Retry-After may indicate a wait. Its absence does not justify immediate retry loops. Counters should reflect multiple instances and expensive routes.
Deliverable: responses and counting policy.
- 03
Bound recovery
Limit both attempts and total elapsed time. Spread retries using progressive delays and random variation. Honor the received delay and handle clock differences for HTTP dates. For external effects, first check whether an operation already completed and provide duplicate protection.
Deliverable: client recovery policy.
- 04
Exercise saturation and restoration
In an authorized environment test bursts, sustained load, shared-IP clients, multiple instances and counter outages. Verify availability of important tasks and prevent every client from retrying together after recovery. Measure justified rejections and legitimate users incorrectly blocked.
Deliverable: reproducible tests and tuning decision.
Reusable worksheet
Complete with your authorised observations. These fields are a working template, not observed results.
| Field | Information to record |
|---|---|
| Limit | Unit, window, identity and route |
| Exceedance | Response, delay and user message |
| Recovery | Attempt budget, duplicates and stopping |
| Evidence | Tested load, rejections and restoration |
Worked example
Illustrative situation
Fictional example: a catalog synchronization receives 429 and every client immediately retries.
Decision and expected evidence
The client honors waiting time, spreads retries, retains a cursor and checks operations already applied.
Distinguish the mechanisms
| Mechanism | Purpose | Check or limitation |
|---|---|---|
| Rate limit | Bound arrivals within a window | May still allow slow, expensive work |
| Concurrency limit | Bound simultaneous processing | Does not bound monthly consumption alone |
| Consumption quota | Bound cumulative usage | Specify renewal and billed units |
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Rejections | Rejected requests by route and identity | Separate abuse from legitimate clients |
| Useful retries | Attempts producing a unique result | Reduce loops and duplicates |
Common pitfalls
- May still allow slow, expensive work
- Does not bound monthly consumption alone
- Specify renewal and billed units
Frequently asked questions
Is HTTP 429 sufficient protection?
No. It describes rejection; cost, concurrency, queues and client behavior also require control.
Is Retry-After always a number?
No. HTTP allows delay seconds or an HTTP date. Clients should recognize both forms.
Can every request be retried automatically?
No. For a non-idempotent effect a lost response may conceal success. Recovery must check business state.
Official references
References consulted: . The method and worksheet propose checks to adapt to your context; they do not constitute certification.
Continue exploring
Related analysis
