Why Redis Streams and Lua? The Dynamic Duo Explained

Before we get our hands dirty with code, let's break down why this combo is the Batman and Robin of rate limiting:

  • Redis Streams: Think of it as a supercharged message queue with time-travel capabilities.
  • Lua Scripts: The Swiss Army knife of Redis (oops, I promised not to use that phrase—let's say "the multi-tool") that lets you execute complex logic atomically.

Together, they're like peanut butter and jelly, if peanut butter could process millions of requests per second and jelly could execute atomic operations. Yum.

The Blueprint: Building Our Custom Rate Limiter

Here's the game plan:

  1. Use Redis Streams to log incoming requests.
  2. Implement a sliding window algorithm with Lua scripts.
  3. Add some spice with dynamic rate adjustments based on server load.

Step 1: Logging Requests with Redis Streams

First things first, let's set up our stream to log those incoming requests:


import redis

r = redis.Redis(host='localhost', port=6379, db=0)

def log_request(user_id):
    return r.xadd('requests', {'user_id': user_id})

Simple, right? We're just adding each request to a stream called 'requests'. The beauty of streams is that they're time-ordered, which is perfect for our sliding window approach.

Step 2: The Lua Script - Where the Magic Happens

Now, let's write a Lua script that will:

  • Check the number of requests in the last X seconds
  • Decide if the request should be allowed
  • Clean up old entries

local function check_rate_limit(user_id, max_requests, window_size_ms)
    local now = redis.call('TIME')
    local now_ms = tonumber(now[1]) * 1000 + tonumber(now[2] / 1000)
    local window_start = now_ms - window_size_ms
    
    -- Remove old entries
    redis.call('XTRIM', 'requests', 'MINID', tostring(window_start))
    
    -- Count requests in the window
    local count = redis.call('XLEN', 'requests')
    
    if count < max_requests then
        -- Allow the request
        redis.call('XADD', 'requests', '*', 'user_id', user_id)
        return 1
    else
        -- Rate limit exceeded
        return 0
    end
end

return check_rate_limit(KEYS[1], tonumber(ARGV[1]), tonumber(ARGV[2]))

This script is doing a lot of heavy lifting:

  • It calculates the current time in milliseconds
  • Trims the stream to keep only recent entries
  • Counts the requests in the current window
  • Decides whether to allow the request

Step 3: Putting It All Together

Now, let's wrap this up in a Python function:


lua_script = """
-- Our Lua script from above goes here
"""

rate_limiter = r.register_script(lua_script)

def is_allowed(user_id, max_requests=100, window_size_ms=60000):
    return bool(rate_limiter(keys=[user_id], args=[max_requests, window_size_ms]))

# Usage
if is_allowed('user123'):
    print("Request allowed!")
else:
    print("Rate limit exceeded!")

Leveling Up: Dynamic Rate Adjustments

But wait, there's more! What if we could adjust our rate limit based on server load? Let's add a twist to our Lua script:


-- Add this to the top of our Lua script
local server_load = tonumber(redis.call('GET', 'server_load') or "50")
local dynamic_max_requests = math.floor(max_requests * (100 - server_load) / 100)

-- Then use dynamic_max_requests instead of max_requests in our logic

Now, we're adjusting our rate limit based on a 'server_load' value stored in Redis. You could update this value periodically based on your actual server metrics.

The Pitfalls: What Could Go Wrong?

Before you rush off to implement this in production, let's talk about some potential gotchas:

  • Memory Usage: Streams can eat up memory if not trimmed properly. Keep an eye on your Redis memory usage.
  • Clock Skew: If you're running this across multiple servers, make sure their clocks are synchronized.
  • Lua Script Complexity: Remember, Lua scripts block Redis. Keep them short and sweet.

Wrapping Up: Why This Matters

So, why go through all this trouble when you could just use a pre-built solution? Here's why:

  • Flexibility: You can adapt this to any weird and wonderful rate limiting scheme you can dream up.
  • Performance: This setup can handle an insane number of requests per second.
  • Learning: Building this from scratch gives you a deep understanding of rate limiting concepts.

Plus, let's be honest, it's just plain cool to say you built your own rate limiter.

Food for Thought

"The only way to do great work is to love what you do." - Steve Jobs

As we wrap up this journey into custom rate limiting, ask yourself: What other "standard" components could benefit from a custom, Redis-powered makeover? The possibilities are endless, limited only by your imagination (and maybe your Redis instance's memory).

Now go forth and rate limit with style! Your APIs will thank you, and who knows, maybe you'll be the talk of the next dev meetup. "Oh, you're using a off-the-shelf rate limiter? That's cute."