Throttling and 429 Too Many Requests: rate limits explained
A rate limit caps how many requests per second a service accepts. Requests above the limit are refused immediately — usually with HTTP 429 Too Many Requests.
What causes it
Most rate limits are token buckets: tokens refill at the limit rate and a burst allowance lets short spikes through. When traffic stays above the refill rate, the bucket empties and every extra request is rejected. Clients that retry immediately make it worse; clients that back off with jitter let the bucket refill.
How to recognise it
- HTTP 429, “ProvisionedThroughputExceededException” or S3 “503 SlowDown”
- Accepted rate flat at exactly the limit
- Errors arrive in bursts after traffic spikes
The math
Accepted ≈ min(arrival rate, refill rate) after the burst is spent
Error messages you will see
| Error | Seen in |
|---|---|
429 Too Many Requests | Users, Router, Server, Database, Cache, Queue and 212 more |
ProvisionedThroughputExceededException | Amazon DynamoDB |
503 SlowDown: Please reduce your request rate | Amazon S3 |
429 Request rate is large (RU/s exceeded) | Azure Cosmos DB |
How to fix it
- Raise the limit or request a quota increase
- Smooth bursts with a queue
- Retry with exponential back-off and jitter
- Spread keys across more prefixes/partitions
Reproduce it in the simulator
Open the simulator, build a small architecture and use Fault injection in the inspector, or push traffic past a component’s capacity.
Learn more
Part of the guide Load balancing and capacity planning.