API throttling vs rate limiting
Rate limiting and throttling are often used interchangeably but have a meaningful distinction in production systems. Rate limiting is a client-side policy: it enforces a maximum request rate per client, rejecting excess requests with a 429. Throttling is a server-side or network-level policy: it slows down or delays requests when the system is under stress, regardless of per-client counts. Throttling preserves service availability by sacrificing response time; rate limiting preserves service availability by rejecting requests.
Why it matters in practice
The two show up as different status codes and need different client responses. A 429 from an API Gateway usage plan is rate limiting - the client's quota is spent, so back off and retry after the window resets. A DynamoDB capacity-exceeded error or a 503 under load is throttling - the service is protecting itself, so retrying harder just deepens the overload. Treat them the same and you either give up on quota that would have refilled, or hammer a service that needed you to stop.
Common mistakes
- •Implementing only rate limiting without throttling - if all clients are within their per-client limits but aggregate traffic exceeds server capacity, you need a global throttle as well.
- •Treating all 4xx/5xx responses as equivalent for retry purposes - 429 should trigger a slower retry (wait for Retry-After), 503 may indicate transient issues that recover faster.