Jan Mikoláš
Glossary
Rate limiting
It limits the pace of requests, not the trustworthiness of a client. It is one layer of operational control and security, not a replacement for authentication or authorization.
Short definition
How much work a given group may start within a given period.
Rate limiting counts requests by a chosen identity—such as an API key, user, tenant, endpoint, or a combination of them—and rejects, defers, or slows them when a rule is exceeded. It protects databases, public APIs, login flows, expensive exports, and integrations calling marketplaces.
It is not only a defence against abuse. An application can use its own limiter as a client to avoid exceeding an external quota. The crucial points are to clearly define what is counted, who owns the limit, whether a short burst is allowed, and what happens when the counter store is unavailable.
Use cases
For protection and pacing
The same principle applies both when receiving requests through your own API and when calling an external service.
- a public API by API key, user, tenant, and endpoint
- login, password reset, and other operations exposed to automated attempts
- an expensive export, search, or report generation
- controlling request volume to a carrier, marketplace, or AI service
- limiting concurrent imports as a separate rule alongside request rate
Practical example
Synchronising inventory to a marketplace
A marketplace allows a limited number of requests per period for each store. Before a call, a worker atomically removes a token from a bucket for the marketplace account. If no token remains, it schedules the job for later instead of entering a tight retry loop.
If the marketplace returns 429 with Retry-After, the application pauses new requests for that account at least until the stated time. Other accounts and more important local work continue. The write still uses a stable external identity because the limiter does not prevent a duplicate effect after a timeout.
How it works
From client identity to a 429 response
In a distributed application, the decision must be atomic and communicated clearly to the client.
- Partition key The service determines whose usage the limit counts. An IP address alone is often insufficient; proxy headers should be relied on only when set by a trusted reverse proxy.
- Policy Defines the window, capacity, cost per operation, allowed burst, and possibly a separate concurrency limit.
- Atomic counting Across multiple instances, checking and changing the counter happen in one shared step, for example in Redis with a TTL.
- Result If quota remains, the request proceeds. Otherwise, the API usually returns 429 Too Many Requests or a worker defers the job.
- Client response The client respects Retry-After, spreads out subsequent requests, and does not block unrelated priorities.
Important concepts
The algorithm determines the trade-off between accuracy and capacity.
No single algorithm suits every endpoint.
Fixed and sliding windows
A fixed window is efficient, but at its boundary it permits a brief double burst. A sliding window is more accurate; logging individual requests uses more memory, while a counter-based approximation is a compromise.
Token and leaky buckets
A token bucket gradually replenishes tokens and allows a limited burst. A leaky bucket releases work evenly; queueing may increase latency.
429 and Retry-After
HTTP 429 reports that the applicable request limit has been exceeded. Retry-After can state the earliest next attempt; custom X-RateLimit headers are not a universal standard.
Rate, throttle, quota, concurrency
A rate limit controls pace, while throttling may slow traffic, a quota defines consumption over a longer period, and a concurrency limit controls the number of expensive operations currently running.
Benefits and limitations
More predictable capacity, not an impenetrable defence.
Benefits
- protecting expensive operations and dependent services from spikes
- fairer use of shared capacity among tenants
- clear client behaviour when a quota is exceeded
- controlling your own workers against external API limits
Risks
- an IP-based limit harming legitimate users behind NAT
- a non-atomic counter allowing requests through across multiple instances
- long queueing merely shifting the problem into latency
- an overly strict global limit harming customers and operations
Scope of use
The degree of restriction should match a specific risk.
Login, export, and marketplace writes do not have the same cost or client identity. Separate limits for sensitive endpoints are clearer than one global number. Remaining quota is only a guide: another parallel request or a higher-level rule may still reject the next call.
Rate limiting is not a complete DDoS defence or a replacement for a WAF, password protection, validation, or antifraud rules. It helps manage application capacity, but a network attack must also be addressed at infrastructure layers.
What to consider
Rules must be measurable and fair.
Limits are both product and technical rules; the client must know what happened, and the team must see their impact.
- a clearly defined partition key and policy for trusting proxy headers
- an atomic distributed operation and a rule for limiter-store outages
- separate limits for critical endpoints, tenants, and expensive operations
- a 429 response with appropriate instructions for the next attempt
- monitoring rejections, backlogs, and changes in client behaviour
Common questions
What rate limiting means for a client
Is HTTP 429 the same as 503?
No. A 429 response says the client exceeded a limit. A 503 response means the service is temporarily unavailable; both responses may contain Retry-After.
Should limits be based only on IP address?
Usually not. An IP address is a supplementary signal; for an API, a key, user, tenant, or combination with the endpoint is often more accurate.
When should I use a token bucket?
When a service can tolerate a limited short burst while maintaining a long-term average. An exact sliding window has different costs and properties.
Is rate limiting a security solution?
It is one protective layer. It does not replace authentication, authorization, a WAF, or account and password protection.
How I manage integration flows in practice
I design request pacing around service limits and the cost of failure.
For API integrations, I address pagination, quotas, retries, idempotence, and operational monitoring of failed synchronisations.