What is Rate Limiting?
Updated: 3 days ago
Rate limiting is a control that restricts how quickly requests, connections or other actions are accepted over a defined period. A service might allow 100 API requests per minute for each user, API key or IP address, then reject, delay or otherwise constrain activity that exceeds the policy. The purpose is to protect finite capacity, reduce abuse and keep shared systems usable for legitimate clients.
Rate limiting is also called throttling in some contexts, but the terms are not always implemented identically. It is different from a long-term quota, and it is not the same as simply reducing bandwidth. The key idea is controlling the rate of activity, not necessarily the number of bytes a broadband connection can carry.
How does rate limiting work?
A rate limiter needs a rule, a way to identify the traffic being counted and a decision when the allowance is exhausted. The identity might be a user account, API key, source IP address, device, session or another application-specific key. The policy could be expressed as requests per second, requests per minute, failed logins per account or another measurable event.
Identify the client or traffic key that the policy applies to.
Count or estimate activity over the relevant time period.
Compare the current activity with the configured allowance.
Allow requests that remain within policy.
Reject, delay, queue or otherwise constrain excess requests.
Reset or replenish the allowance according to the chosen algorithm.
The exact implementation matters. A limit of 60 requests per minute does not necessarily mean one request is permitted every second. Depending on the algorithm, a client may be able to send a short burst and then wait for capacity to become available again.
What happens when a rate limit is exceeded?
For HTTP services, a common response is 429 Too Many Requests. RFC 6585 defines 429 as indicating that the user has sent too many requests in a given amount of time. The response may include Retry-After to tell the client how long to wait before trying again.
The RFC 6585 specification deliberately does not prescribe how a server identifies a user or counts requests. Those are policy and implementation choices. It also notes that under very heavy attack a server is not required to spend resources returning a 429 response to every request.
A well-behaved API client should reduce its request rate after receiving a 429 response and honour Retry-After when it is supplied. Repeatedly retrying immediately can make the situation worse and may trigger stricter controls.
Rate limiting vs throttling vs quotas vs concurrency limits
Rate limiting: controls how many actions are accepted during a relatively short time window.
Throttling: often used as a synonym for rate limiting, although some systems use it specifically for slowing activity rather than rejecting it.
Quota: limits total usage over a longer period, such as a monthly API allowance. NIST SP 800-228 explicitly distinguishes quotas from rate limits.
Concurrency limit: caps how many requests, sessions or operations may be active at the same time.
Bandwidth limit: caps data transfer capacity or rate. It can be related to traffic management but is not automatically request rate limiting.
These controls can exist together. An API could permit 100 requests per minute, allow no more than 10 concurrent requests and enforce a separate monthly quota. Each control protects a different dimension of capacity.
Common rate limiting algorithms
Fixed window
A fixed-window limiter counts events within discrete periods, such as each clock minute. It is straightforward to understand, but activity near the boundary between two windows can create a burst that is much larger than the apparent average rate.
Sliding window
A sliding-window approach evaluates activity across a moving time period rather than a fixed clock boundary. It can produce smoother enforcement, but accurate tracking may require more state or computation.
Token bucket
A token bucket replenishes tokens at a configured rate. Each permitted action consumes a token. Unused tokens can accumulate up to the bucket capacity, allowing controlled bursts while preserving the longer-term average rate.
Leaky bucket
A leaky-bucket design models work leaving a queue at a controlled rate. It is useful for smoothing bursts, although implementations and terminology vary. The important point is that different algorithms can behave differently even when they advertise a similar requests-per-second figure.
Techie Broadband example: why the algorithm changes the result
Techie Broadband calculation: suppose an API allows 120 requests per minute. The simple average is 120 ÷ 60 = 2 requests per second. That does not prove the service will accept exactly two requests during every individual second.
With a strict per-second rule, a burst of 20 requests in one second could be rejected even if the previous 59 seconds were idle.
With a token bucket that has accumulated spare tokens, some or all of the same burst might be accepted.
With a fixed one-minute window, traffic concentrated around the boundary between two minutes can produce a much larger short burst than the 2 requests-per-second average suggests.
This is why a published number such as 120 requests per minute is incomplete without understanding the burst allowance, counting key, window and enforcement behaviour.
Why do websites and APIs use rate limiting?
Protecting application and database capacity from excessive request volume.
Sharing finite resources more fairly between customers or users.
Reducing automated scraping and abusive API use.
Slowing online password guessing and credential attacks.
Containing accidental request loops or poorly behaved software.
Reducing the impact of some traffic spikes before they exhaust downstream resources.
Enforcing product or service usage policies.
Rate limiting can complement a firewall, packet inspection and other controls, but it solves a different problem. A firewall decides whether traffic is permitted according to policy. A rate limiter additionally considers how quickly permitted-looking activity is arriving.
Does rate limiting stop DDoS attacks?
Rate limiting can be part of a DDoS mitigation strategy, but it is not a complete DDoS defence. If an attack saturates the victim's internet link before traffic reaches the local limiter, the limiter cannot recover bandwidth that has already been consumed upstream.
Distributed attacks also complicate identity-based limits. A per-IP rule that constrains one abusive address may be much less effective when traffic arrives from thousands of different source addresses. Effective DDoS mitigation can require upstream filtering, traffic scrubbing, anycast distribution, content delivery infrastructure and other controls positioned before the constrained resource.
RFC 7480 makes this distinction explicitly for RDAP services: HTTP rate limiting can deter scraping and abuse, but a malicious client can ignore a 429 response and continue sending traffic. Rate limiting therefore needs to be placed in the wider context of capacity protection.
Rate limiting and login security
Rate limiting is particularly important for online authentication because an attacker may otherwise be able to make large numbers of password or authenticator guesses. Current NIST digital identity guidance requires rate limiting for relevant authenticator types and discusses delays and bot-detection controls as ways to reduce automated guessing.
The design needs care. An attacker may deliberately trigger a limit against somebody else's account to cause a denial of service. This is one reason mature systems consider account identity, source information, risk signals, progressive delays and recovery behaviour rather than relying on one crude permanent lockout rule.
Rate limiting on a home or UK broadband connection
Most home broadband users do not configure HTTP API rate limits for ordinary web browsing. The concept becomes relevant when you run internet-facing services, self-host applications, use cloud APIs, operate a home lab, expose authentication endpoints or troubleshoot a service that starts returning 429 responses.
Your FTTP, FTTC, cable or mobile broadband speed is a separate constraint. A rate-limited API can refuse requests even when your connection has abundant spare capacity. Conversely, a server may permit your request rate while your actual transfer performance is limited elsewhere by latency, WiFi, routing, server capacity or the broadband path.
If you host a service from home, remember that a local rate limiter only sees traffic after it has reached your connection. It can protect the application and local compute resources, but it cannot by itself prevent a sufficiently large inbound flood from filling the broadband link.
Rate limiting behind CGNAT, proxies and shared IP addresses
A simple per-IP limit can affect multiple people when many users appear to a service from the same public address. This can happen behind corporate proxies, carrier networks and CGNAT. A service that treats one public IP address as one person may therefore throttle legitimate users together.
The opposite problem also exists: an attacker with many source addresses may spread requests across them to avoid a per-IP threshold. Good rate-limit design chooses an identity dimension that fits the service, such as an authenticated account or API key, and may combine several signals.
How to troubleshoot a 429 Too Many Requests error
Stop immediate retries. Repeated retries can extend the problem or consume the next available allowance.
Read the response and documentation for Retry-After, rate-limit headers or a stated request policy.
Check whether several devices, processes or users share the same account, API key or public IP address.
Look for software loops, aggressive polling, parallel jobs or retry logic that may be generating more requests than expected.
Reduce request frequency and add exponential backoff or jitter where appropriate.
Cache results and batch work where the API supports it instead of requesting the same information repeatedly.
If you operate the service, inspect which identity or key triggered the limit and whether legitimate users are being grouped incorrectly.
Do not assume your broadband connection is faulty simply because a remote API is returning 429. Test the wider connection separately.
A 429 response is an application or HTTP-level signal from the service you are using. It is not a broadband speed test and does not by itself show congestion on your ISP network.
Rate limiting can create its own bottleneck
A rate limiter sits on a request path and therefore needs enough capacity to evaluate the traffic it is intended to control. If the limiter depends on a slow central datastore, performs expensive checks or becomes a single point of contention, the protective control can itself constrain the service.
Distributed systems also need to decide whether counters are local to each server or coordinated across the fleet. Perfect global counting can be expensive. In practice, some systems accept approximate enforcement in exchange for scalability and resilience. The right trade-off depends on what the limit is protecting.
Common misconceptions about rate limiting
Rate limiting does not mean your broadband provider has reduced your line speed.
HTTP 429 does not automatically mean the website is under attack.
A per-IP limit does not necessarily represent one human user.
A rate limit is not automatically a monthly quota.
Rate limiting does not guarantee DDoS protection.
A published requests-per-minute value does not fully describe burst behaviour.
More generous limits are not automatically better if the protected service cannot safely handle the resulting load.
Key takeaway
Rate limiting protects finite resources by controlling how quickly clients can perform actions. The useful questions are not only 'what is the number?' but also 'what is being counted, over what period, for which identity, with what burst allowance, and what happens when the limit is exceeded?' Those details determine how the control behaves in the real world.
Rate limiting FAQs
What does rate limiting mean?
Rate limiting means restricting the number or frequency of actions accepted during a defined period. It is commonly applied to API requests, login attempts, connections and other finite resources.
What is HTTP 429?
HTTP 429 Too Many Requests indicates that the client has sent too many requests in a given amount of time. A server may include Retry-After to indicate when the client should try again.
Is rate limiting the same as throttling?
The terms are often used interchangeably, but implementations may use throttling specifically for slowing or delaying activity while rate limiting can also reject requests. Check the product or API documentation for the exact behaviour.
Is rate limiting the same as a quota?
No. A rate limit normally controls short-term activity, while a quota usually limits total usage across a longer period such as a day or month.
Can rate limiting stop a DDoS attack?
It can reduce some forms of abusive traffic and protect application resources, but it cannot by itself stop every DDoS attack. Upstream capacity can be saturated before traffic reaches a local limiter.
Does a 429 error mean my broadband is too slow?
No. A 429 response means the remote service is enforcing a request policy. Your broadband connection can be working normally at the same time.
To explore the related technical concepts used in this Rate Limiting guide, visit our broadband terminology guide.
