Web Security
Algorithms, identifiers, distributed coordination, and response design for resource limits.
Rate limiting controls how frequently an identity may consume a constrained operation or resource. A complete policy combines an algorithm, capacity and refill rules, a stable identifier, distributed state, response behavior, and an explicit failure mode. Fixed windows offer simple accounting but permit boundary bursts; sliding approaches improve recent-history fairness at different memory costs; token buckets permit controlled bursts; and leaky buckets shape output at a steady rate. The implementation must also handle shared networks, rotating attackers, retries, hot keys, store outages, and client guidance through HTTP 429 and retry information. Limits should protect availability without turning shared infrastructure into an avoidable denial of service.
Use the rate limiting guide to compare algorithms first, then choose identifiers and distributed topology based on the protected resource. Finish with response semantics, observability, boundary tests, and outage behavior before enforcing limits.
Token bucket, leaky bucket, sliding window, or fixed window? This guide explains how each rate-limiting algorithm works and when to use it in your API.
Read guideTell a denial-of-service flood from a large customer by identity, not volume. Compare IP, User-Agent, and application fingerprinting with edge DDoS in front.
Read guideAdd Arcjet sliding-window and token-bucket rate limits to SvelteKit form actions with the v1 SvelteKit SDK, Svelte 5 runes, and npx sv create.
Read guideChange Arcjet rate limits at runtime without redeploying. Drive shield and slidingWindow from LaunchDarkly client.variation() on Node 22 LTS and Express 5.
Read guide