Rate Limiting

The simplest rate limiting strategy that divides time into discrete, non-overlapping intervals (e.g., 60-second windows). A counter resets to zero at the start of each window. Critical flaw: a burst of requests at the window boundary can effectively double the allowed rate, creating a stampeding herd vulnerability.

• Counter key: user_id:window_timestamp
• Reset boundary: Strict wall-clock alignment
• Use case: Coarse-grained API quotas where precision is secondary

A precise algorithm that maintains a timestamped log of every request. For each new request, the system evicts entries older than the window duration and counts the remainder. This provides exact rate enforcement but consumes significant memory under high throughput.

• Data structure: Sorted set or time-series log
• Precision: Perfect, no boundary artifacts
• Cost: O(N) memory where N is requests per window
• Production note: Often implemented with Redis sorted sets using ZREMRANGEBYSCORE

A flexible algorithm where a virtual bucket is refilled with tokens at a steady rate up to a maximum capacity. Each request consumes one token; if the bucket is empty, the request is rejected. This elegantly handles burst tolerance while enforcing a long-term average rate.

• Parameters: Refill rate (tokens/sec) and bucket capacity (max burst)
• Burst behavior: Full bucket allows instantaneous burst up to capacity
• Implementation: Often uses a leaky bucket variant for network traffic shaping
• Analogy: A bouncer letting in patrons at a steady pace, but allowing a line to queue briefly

A queue-based algorithm that processes requests at a constant rate regardless of arrival pattern. Excess requests are queued in a FIFO buffer; if the buffer overflows, requests are discarded. This smooths bursty traffic into a uniform outflow, making it ideal for network traffic shaping.

• Queue depth: Determines burst absorption capacity
• Output rate: Fixed, invariant processing speed
• Difference from token bucket: Leaky bucket enforces constant outflow; token bucket allows bursts
• Use case: Ingress traffic shaping at load balancers and API gateways

An approximation algorithm that combines the low memory footprint of fixed windows with the boundary-smoothness of sliding logs. It calculates the weighted count from the previous window based on how far the current timestamp has progressed. Industry standard for high-scale API gateways.

• Formula: count = previous_window_count * (1 - elapsed_ratio) + current_window_count
• Accuracy: Within 1-2% of true sliding window log
• Memory: Only two counters per client
• Adopted by: Kong, NGINX rate limiting module, Cloudflare

The challenge of enforcing a global rate limit across multiple application instances or edge nodes. Requires a shared state backend (typically Redis or Memcached) with atomic increment operations. Race conditions between check-and-increment steps must be mitigated via Lua scripting or compare-and-swap semantics.

• Consistency model: Eventually consistent vs. strongly consistent
• Synchronization cost: Network round-trip to shared store per request
• Optimization: Local counters with periodic sync for relaxed limits
• Failure mode: Fail-open (allow traffic) vs. fail-closed (block traffic) when backend is unreachable

The heuristic examination of request timing, URL traversal logic, and session depth to distinguish the methodical, high-volume behavior of bots from the stochastic, intermittent browsing patterns of humans. Rate limiting provides the raw telemetry—request frequency and burst patterns—that feeds into these behavioral models.

• Analyzes inter-request timing distributions
• Detects linear page traversal vs. random human browsing
• Identifies session depth anomalies

A security service deployed at the content delivery network edge that uses machine learning and fingerprinting to detect, categorize, and mitigate automated traffic before it reaches the origin server. Rate limiting is one primitive within these platforms, working alongside JA4 fingerprinting and CAPTCHA challenges.

• Operates at CDN layer before origin traffic
• Aggregates rate signals with fingerprinting data
• Enforces graduated responses: throttle, challenge, block

A probabilistic rating assigned to a session or request by a detection engine, aggregating signals from IP reputation, fingerprinting, and behavioral analysis to determine the likelihood of automation. Rate limit counters are a primary input signal—a high request velocity directly elevates the bot score.

• Composite score from multiple detection signals
• Rate thresholds are weighted heavily in scoring
• Triggers automated mitigation at defined thresholds

A cryptographic challenge that requires the client to expend significant CPU cycles to solve a mathematical puzzle before access is granted. This imposes an economic cost on large-scale scraping operations, making each request computationally expensive rather than merely rate-limited.

• Client must compute hash solution before access
• Cost scales linearly with request volume
• Complements rate limiting with economic disincentive

A dynamic trust score assigned to an IP address based on historical behavior, threat intelligence feeds, and association with malicious activity. Rate limiting decisions are often preconditioned on reputation—high-reputation IPs receive generous thresholds while low-reputation ranges face aggressive throttling.

• Integrates with commercial threat intelligence feeds
• Preemptively restricts known scraper IPs
• Enables tiered rate limit policies by reputation band

A defensive mechanism involving an invisible link or form field hidden from human users via CSS but visible to parsers. When an automated agent interacts with the trap, it is immediately identified and blocked, bypassing rate limit counters entirely through definitive bot confirmation.

• Hidden via CSS display:none or off-screen positioning
• Legitimate users never interact with the element
• Provides high-confidence bot classification signal