Rate Limiting with Redis: INCR+EXPIRE and Sliding Window

Rate limiting with Redis is a classic use case because Redis's atomic operations make counter increments safe under concurrent requests from multiple application instances — something in-memory counters can't handle in a distributed deployment.

Fixed window with INCR

• The simple approach: INCR ip:192.168.1.1:2024-01:16:30 increments a counter for this IP in this minute; EXPIRE sets the TTL to 60 seconds so the counter resets automatically
• INCR is atomic — no two concurrent requests can read and write the counter simultaneously without both their increments being recorded
• The limitation: fixed windows allow bursting at the window boundary — a client can send 100 requests at 11:59 and 100 requests at 12:00, totaling 200 in a 2-second window even though the limit is 100 per minute

Sliding window with Sorted Set

• ZADD requests ip:192.168.1.1 timestamp requestId adds the request timestamp as the score; ZREMRANGEBYSCORE removes entries older than the window; ZCARD counts remaining entries
• This gives a true sliding window — the count reflects requests in the last N seconds from now, not from the start of the current minute period; no boundary burst is possible
• Slightly more expensive than INCR: three commands vs one, wrapped in a Lua script for atomicity

Token bucket with Lua script

• The most accurate rate limiting model — each client has a bucket of tokens that refills at a fixed rate; each request consumes one token; if the bucket is empty, the request is rejected
• Implement in a Lua script (EVAL) to make the read-compute-write atomic in Redis; or use the Bucket4j library which integrates with Redis for Spring Boot applications

Bucket4j with a Redis backend is the recommended production approach for Spring Boot — it provides token bucket semantics, configures via Spring Cloud Gateway, and handles the Lua atomicity automatically.