Rate limiting with sliding window in Redis - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

Sliding Window Rate Limit: Count Requests in Last Minute

Given a Redis sorted set where each member is a timestamp of a user request, which command returns the count of requests made in the last 60 seconds?

Redis

ZCOUNT user:123:requests -inf +inf

A ZCOUNT user:123:requests (current_timestamp - 60) current_timestamp

B ZCOUNT user:123:requests (current_timestamp - 60) +inf

C ZCOUNT user:123:requests -inf (current_timestamp - 60)

D ZCOUNT user:123:requests current_timestamp (current_timestamp + 60)

💡 Hint

Use ZCOUNT with a score range to count timestamps within the last 60 seconds.

ZCOUNT with the range from (current_timestamp - 60) to current_timestamp counts all requests in the last 60 seconds. Using +inf or -inf incorrectly includes timestamps outside the window.

📝 Syntax

intermediate

Identify the Correct Redis Command Syntax for Sliding Window Cleanup

Which Redis command syntax correctly removes all request timestamps older than 60 seconds from the sorted set 'user:123:requests'?

A ZREMRANGEBYSCORE user:123:requests (current_timestamp - 60)

B ZREMRANGEBYSCORE user:123:requests (current_timestamp - 60) +inf

C ZREMRANGEBYSCORE user:123:requests -inf (current_timestamp - 60)

D ZREMRANGEBYSCORE user:123:requests -inf current_timestamp

💡 Hint

You want to remove all timestamps less than (current_timestamp - 60).

ZREMRANGEBYSCORE with range -inf to (current_timestamp - 60) removes all older timestamps. Other options either remove wrong ranges or have syntax errors.

❓ optimization

advanced

Optimize Sliding Window Rate Limiting with Redis Lua Script

Which Lua script snippet atomically adds the current timestamp to a sorted set, removes timestamps older than 60 seconds, and returns the count of requests in the last 60 seconds?

A redis.call('ZADD', KEYS[1], ARGV[1], ARGV[1]); redis.call('ZREMRANGEBYSCORE', KEYS[1], '-inf', ARGV[1] + 60); return redis.call('ZCOUNT', KEYS[1], ARGV[1] - 60, ARGV[1])

B redis.call('ZADD', KEYS[1], ARGV[1], ARGV[1]); redis.call('ZREMRANGEBYSCORE', KEYS[1], ARGV[1] - 60, '+inf'); return redis.call('ZCOUNT', KEYS[1], ARGV[1] - 60, ARGV[1])

C redis.call('ZADD', KEYS[1], ARGV[1], ARGV[1]); redis.call('ZREMRANGEBYSCORE', KEYS[1], '-inf', ARGV[1] - 60); return redis.call('ZCOUNT', KEYS[1], '-inf', ARGV[1])

D redis.call('ZADD', KEYS[1], ARGV[1], ARGV[1]); redis.call('ZREMRANGEBYSCORE', KEYS[1], '-inf', ARGV[1] - 60); return redis.call('ZCOUNT', KEYS[1], ARGV[1] - 60, ARGV[1])

💡 Hint

Remove timestamps older than (current_timestamp - 60) and count timestamps in the last 60 seconds.

Option D correctly removes old timestamps and counts requests in the last 60 seconds. Other options remove wrong ranges or count incorrectly.

🔧 Debug

advanced

Debug Sliding Window Rate Limiting: Unexpected High Count

A developer uses this Redis command to count requests in the last 60 seconds:

ZCOUNT user:123:requests -inf (current_timestamp - 60)

but notices the count is unexpectedly high. What is the cause?

A The command syntax is invalid and causes a runtime error.

B The command counts timestamps older than (current_timestamp - 60) instead of newer ones.

C The command counts timestamps newer than (current_timestamp - 60) correctly.

D The command counts timestamps between (current_timestamp - 60) and +inf correctly.

💡 Hint

Check the score range used in ZCOUNT and what it includes.

Using -inf to (current_timestamp - 60) counts all timestamps older than 60 seconds ago, causing a high count. The correct range should be from (current_timestamp - 60) to current_timestamp.

🧠 Conceptual

expert

Why Use Sliding Window Rate Limiting Over Fixed Window?

Which statement best explains the advantage of sliding window rate limiting compared to fixed window rate limiting?

A Sliding window provides a smoother and more accurate limit by counting requests in a moving time frame, avoiding bursts at window edges.

B Fixed window rate limiting uses sorted sets, while sliding window uses simple counters.

C Fixed window rate limiting counts requests continuously without resetting, unlike sliding window.

D Sliding window is easier to implement and requires less memory than fixed window.

💡 Hint

Think about how requests are counted over time in both methods.

Sliding window counts requests in a continuously moving time frame, preventing sudden bursts at window boundaries that fixed windows allow. This makes it more precise and fair.

Practice

1. What is the main purpose of using a sliding window in rate limiting with Redis?

easy

A. To count actions within a moving time frame for fair limits

B. To store user passwords securely

C. To permanently block users after one action

D. To sort data alphabetically

Solution

1. Step 1: Understand sliding window concept

   Sliding window rate limiting counts actions in a recent time frame that moves forward as time passes.

2. Step 2: Identify purpose in Redis context

   Redis uses sorted sets to track timestamps of actions to enforce limits fairly over time.

3. Final Answer:

   To count actions within a moving time frame for fair limits -> Option A

4. Quick Check:

   Sliding window = moving time frame count [OK]

Hint: Sliding window means counting recent actions, not all time [OK]

Common Mistakes:

• Thinking sliding window blocks permanently
• Confusing with password storage
• Assuming it sorts data alphabetically

2. Which Redis command is essential to add a timestamp to a sorted set for sliding window rate limiting?

easy

A. ZADD

B. GET

C. HSET

D. LPUSH

Solution

1. Step 1: Identify command to add to sorted set

   ZADD adds members with scores (timestamps) to a sorted set in Redis.

2. Step 2: Confirm other commands' purpose

   GET retrieves string values, HSET sets hash fields, LPUSH adds to lists, none add to sorted sets.

3. Final Answer:

   ZADD -> Option A

4. Quick Check:

   ZADD adds to sorted set [OK]

Hint: Use ZADD to add timestamps to sorted sets [OK]

Common Mistakes:

• Using GET which only reads strings
• Confusing HSET (hashes) with sorted sets
• Using LPUSH which is for lists

3. Given this Redis Lua script snippet for sliding window rate limiting:

local now = tonumber(redis.call('TIME')[1])
redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local count = redis.call('ZCARD', key)
if count < limit then
  redis.call('ZADD', key, now, now)
  return 1
else
  return 0
end

What will be the return value if the current count is equal to the limit?

medium

A. 1

B. nil

C. 0

D. An error

Solution

1. Step 1: Analyze the condition count < limit

   If count is equal to limit, the condition count < limit is false.

2. Step 2: Determine return value when condition is false

   When false, the script returns 0, indicating rate limit reached.

3. Final Answer:

   0 -> Option C

4. Quick Check:

   count == limit returns 0 [OK]

Hint: If count equals limit, return 0 (limit reached) [OK]

Common Mistakes:

• Assuming count == limit returns 1
• Expecting an error instead of 0
• Thinking nil is returned

4. You have this Redis Lua script for sliding window rate limiting:

local now = tonumber(redis.call('TIME')[1])
redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local count = redis.call('ZCARD', key)
if count <= limit then
  redis.call('ZADD', key, now, now)
  return 1
else
  return 0
end

What is the bug in this script?

medium

A. ZREMRANGEBYSCORE is used incorrectly

B. Using <= allows one extra request beyond limit

C. ZADD should use a string member, not number

D. TIME command returns a string, not number

Solution

1. Step 1: Check condition count <= limit

   This condition allows adding a request when count equals limit, exceeding limit by one.

2. Step 2: Verify other commands usage

   ZREMRANGEBYSCORE usage is correct to remove old timestamps; ZADD accepts numbers as members; TIME returns array with string seconds converted to number.

3. Final Answer:

   Using <= allows one extra request beyond limit -> Option B

4. Quick Check:

   count <= limit allows limit+1 requests [OK]

Hint: Use < not <= to enforce strict limit [OK]

Common Mistakes:

• Thinking ZREMRANGEBYSCORE is wrong here
• Believing ZADD can't use numbers as members
• Confusing TIME return type

5. You want to implement a sliding window rate limiter in Redis that allows 100 requests per 60 seconds. Which sequence of Redis commands best enforces this limit efficiently?

hard

A. HSET to store count, GET to read count, INCR to increment count

B. LPUSH to add timestamp, LLEN to count, LTRIM to remove old timestamps

C. SETNX to set a flag, EXPIRE to reset after 60 seconds

D. ZREMRANGEBYSCORE to remove old timestamps, ZCARD to count, ZADD to add current timestamp

Solution

1. Step 1: Understand sliding window enforcement

   Use sorted sets to store timestamps, remove old ones, count current requests, and add new timestamp.

2. Step 2: Evaluate each option's commands

   ZREMRANGEBYSCORE to remove old timestamps, ZCARD to count, ZADD to add current timestamp uses ZREMRANGEBYSCORE, ZCARD, ZADD correctly for sliding window. LPUSH to add timestamp, LLEN to count, LTRIM to remove old timestamps uses lists which are less efficient for range removals. HSET to store count, GET to read count, INCR to increment count uses hashes and counters, not suitable for sliding window. SETNX to set a flag, EXPIRE to reset after 60 seconds uses simple flags, not counting requests.

3. Final Answer:

   ZREMRANGEBYSCORE, ZCARD, ZADD sequence -> Option D

4. Quick Check:

   Sorted sets + remove old + count + add = correct [OK]

Hint: Use sorted sets with ZREMRANGEBYSCORE, ZCARD, ZADD [OK]

Common Mistakes:

• Using lists which are inefficient for sliding windows
• Using counters without timestamps
• Using flags without counting requests