Why Sentinel Fails for Per‑User Hourly Limits and How Redis + Lua Solves It

Problem Statement

An interview question asks how to limit a single user to at most 10 requests per hour (e.g., 5 orders per hour). The challenge is to enforce a long‑window, low‑frequency limit in a distributed system where multiple gateway instances may receive the same user's requests.

Key Requirements

Distributed consistency: All instances must share a global counter so that a user cannot exceed the quota by hitting different nodes.

Long window + low frequency: The solution must handle hour‑level windows without exploding memory or resetting counts prematurely.

Solution 1: Sentinel Hotspot Parameter Limiting

Scenario

Some developers try to configure Sentinel hotspot parameters for userId with a 1‑hour, 5‑times rule, hoping to avoid code changes.

Key Pitfalls

Sentinel’s ParamFlowRule contains a hard‑coded constant MAX_DURATION_SEC = 1800 (30 minutes). Even if the window is set to 3600 seconds, it is truncated to 30 minutes, breaking the business rule.

The underlying LeapArray uses 1‑second buckets. A 1‑hour window requires 3600 buckets; with 100 k active users this consumes >3 GB memory, causing OOM in gateway instances.

Only the top 1000 hotspot keys are cached (LRU). Ordinary users are evicted, their counters reset, and the limit becomes ineffective.

Pros & Cons

Advantages: Zero extra dependencies, simple configuration, no Lua or code changes.

Disadvantages: Memory explosion for long windows, LRU eviction, hard‑coded window limit.

Suitable for: Short‑window, high‑frequency hotspot protection (e.g., flash‑sale product IDs), not user‑level long‑window limits.

Solution 2: Sentinel Ordinary Flow Control + Cluster Mode

Scenario

After discovering the hotspot limitation, some switch to Sentinel ordinary flow control. They compose a resource name that includes userId (e.g., order:create:user1001) and enable cluster mode so a Token Server aggregates counts across instances.

Key Pitfalls

Memory remains high for long windows; each user still consumes buckets.

Cluster mode introduces a central Token Server. Deploying only one node creates a single point of failure; at least two nodes are required for high availability.

Window granularity must be tuned (e.g., 10‑minute buckets) to reduce bucket count from 3600 to 6, lowering memory usage.

Pros & Cons

Advantages: Guarantees distributed consistency via Token Server; better than hotspot parameters for long windows.

Disadvantages: Still memory‑intensive, requires cluster deployment, not suitable for >100 k users at 10⁵ QPS.

Applicable scenarios: Medium‑scale (≤10 k users) with windows ≤30 minutes; large‑scale e‑commerce spikes are not recommended.

Solution 3: Redis ZSet + Lua Script (Recommended)

Scenario

For 10⁵ QPS e‑commerce peaks, the optimal solution is a Redis sorted set (ZSet) combined with an atomic Lua script that performs three steps in one request: clean up entries older than one hour, count current entries, and add a new entry if the count is below the limit.

Key Code

-- Lua script: key is user:limit:1001, ARGV[1] is current timestamp (seconds)
local now = tonumber(ARGV[1])
-- Remove records older than 1 hour
redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, now - 3600)
local count = redis.call('ZCARD', KEYS[1])
-- If not exceeded 5 times, record the request
if count < 5 then
    redis.call('ZADD', KEYS[1], now, now..math.random())
    redis.call('EXPIRE', KEYS[1], 3600) -- auto‑expire to free memory
    return 1 -- allow
end
return 0 -- reject

Key Considerations

Atomicity: The script bundles cleanup, count, and insert to avoid race conditions where concurrent requests could both see a count below the limit.

Expiration: Setting EXPIRE 3600 prevents stale keys from accumulating; tests show 100 k users occupy only tens of MB.

Performance: A single Redis node can handle dozens of thousands of QPS; a cluster is unnecessary for 10⁵ QPS.

Pros & Cons

Advantages: Supports arbitrary long windows, memory‑controlled, distributed consistency, high throughput.

Disadvantages: Requires Redis and a small Lua script (few lines, easy to maintain).

Applicable scenarios: Large‑scale e‑commerce promotions (≥10⁵ QPS), hour‑level or day‑level user‑level limits.

Solution 4: Guava RateLimiter (Local)

Scenario

Developers sometimes use Guava RateLimiter locally with a configuration like “5 requests per 3600 seconds”. It works for single‑instance testing.

Key Pitfalls

In a distributed deployment each instance maintains its own counter, allowing a user to consume N × quota where N is the number of instances.

Guava’s token‑bucket algorithm smooths traffic, so the effective QPS is ~0.0014, causing low precision (users may make 6 requests before being blocked).

Pros & Cons

Advantages: Zero dependencies, extremely simple for local testing.

Disadvantages: Fails in distributed scenarios, poor precision for long windows.

Applicable scenarios: Local tests or single‑node low‑traffic services; never for production distributed rate limiting.

Core Comparison

Sentinel (both hotspot and ordinary flow) excels at short‑window, high‑frequency hotspot protection but is mismatched for long‑window, low‑frequency user limits due to memory blow‑up, LRU eviction, and hard‑coded window caps. Redis + Lua provides a “ledger” style solution that cleanly handles long windows with controlled memory and global consistency.

Final Recommendation

For user‑level hourly limits in high‑traffic e‑commerce, choose Redis ZSet + Lua as the default solution. Sentinel ordinary flow control with cluster mode can be considered for medium‑scale (<10 k users) and windows ≤30 minutes, provided the bucket granularity is tuned and Token Server is deployed with HA. Guava RateLimiter should be limited to local testing only.

Additional Advanced Option: Edge‑Shard + Nacos Dynamic Weights

When Token Server cannot sustain 5‑10 × 10⁴ QPS, an edge‑sharding approach distributes traffic based on weighted Nginx routing and synchronizes per‑node thresholds via Nacos. This eliminates the central token bottleneck, offers linear scaling, and reduces operational cost, but it only suits global interface‑level QPS limits, not precise per‑user limits.