Skip to main content
Architecture & Engineering

Rate Limiting

Rate limiting caps how many requests a client can make in a given period, protecting a service from being overwhelmed by a single caller — whether malicious, misconfigured or simply busy. Callers that exceed the limit receive a 429 response indicating when they may retry.

Rate limits protect availability for everyone else. One client in a retry loop can consume the capacity an entire service depends on, and without a limit the first sign is an outage affecting unrelated customers. With one, that client degrades and the rest are unaffected.

Good limiting communicates rather than just refuses. Returning a `Retry-After` header and headers describing the remaining quota lets a well-behaved client back off correctly instead of retrying immediately and compounding the problem. Limits should also be per-client rather than global, so one heavy user cannot exhaust the shared allowance.

Codazz builds this in production — API & Backend Development.

FAQ

Rate Limiting
FAQ.

Common questions about rate limiting.

Ask Us Anything

429 Too Many Requests, accompanied by a Retry-After header telling the client how long to wait. Returning 503 is misleading because it suggests the service itself is unavailable, and returning 200 with an error body means well-behaved clients will not back off at all.

Related terms

API Gateway

An API gateway is a single entry point that sits in front of backend services and handles concerns common to all of them — authentication, rate limiting, routing, request validation and logging.

Webhooks

Webhooks are HTTP callbacks that one system sends to another when an event occurs, so the receiver learns about it immediately instead of polling for changes.

Load Balancing

Load balancing distributes incoming requests across multiple servers so no single instance becomes a bottleneck, and so the failure of one instance does not take the service down.

Browse the full glossary →