What is Rate Limiting?

Rate limiting restricts how often a client, account or operation may use a service during a period. A good implementation does not merely count HTTP requests; it protects the scarce resource involved, such as login checks, text messages, password-reset mail, database queries, file exports or the cost of a third-party service.

What does rate limiting help against?

Rate limiting raises the cost of an attack but does not necessarily prevent it. Distributed or very slow attacks can remain below simple thresholds. Against a volumetric DDoS attack that saturates the internet circuit, filtering also needs to happen upstream.

Which identifier should be limited?

The key must match the abuse scenario. A per-IP limit is simple, but it affects many legitimate users behind a mobile gateway or corporate proxy and can be bypassed with distributed sources. A per-account limit alone enables intentional lockout of other people's accounts. Robust systems combine account, API token, session, device, tenant, IP prefix and global capacity according to the operation.

Sensitive or expensive operations need separate limits. One thousand cached reads may be cheaper than ten PDF exports. Authenticated premium users may receive a larger allowance, but they should not gain an unlimited resource.

Which algorithms are available?

The suitable algorithm depends on whether short legitimate bursts are allowed, the cost of exact counting and whether multiple servers must share state.

How should a limit respond?

HTTP APIs commonly respond with 429 Too Many Requests. A Retry-After value or documented rate-limit headers help well-behaved clients adapt. Depending on risk, delay, queueing, a challenge, reduced functionality or temporary blocking may be suitable. The response must not reveal whether an unknown username exists and should not enable easy permanent lockout of another account.

How does it work in distributed systems?

With multiple application instances, enforcement needs consistent state at an API gateway, reverse proxy or shared fast data store. Local counters per server otherwise multiply the effective limit. Applications should accept client-IP headers only from trusted proxies; arbitrary X-Forwarded-For values would permit bypass. Failure of a central limiter requires a conscious choice between fail-open, fail-closed and a safe local fallback.

Which mistakes are common?

• Only the website is limited while mobile or legacy API endpoints remain unrestricted.
• Successful and failed attempts reset the same counter carelessly.
• Limits are hard-coded and their effect on different customer groups is invisible.
• The error response requires almost the same expensive work as the original request.
• One global limit protects capacity but lets an attacker crowd out every legitimate user.

Code example: a Laravel login limit

RateLimiter::for('login', function (Request $request) {
    $email = mb_strtolower((string) $request->input('email'));

    return [
        Limit::perMinute(60)->by('ip:' . $request->ip()),
        Limit::perMinute(5)->by('account:' . hash('sha256', $email)),
    ];
});

Route::post('/login', LoginController::class)
    ->middleware('throttle:login');

The values are examples and need tuning to the user population and risk. The combination slows one source while also protecting a targeted account; one global limit would make it easier to lock out legitimate users.

How are limits tested meaningfully?

Tests cover normal use, permitted bursts, exact boundaries, parallel requests and different keys. Bypass attempts then exercise alternative endpoints, case differences, changing IP headers, multiple nodes and distributed accounts. Monitoring should expose rejected and delayed requests, affected users, resource load and false positives. Only this operational evidence shows whether a limit slows abuse without disrupting legitimate use disproportionately.