I was looking through the logs for our mock Weather API yesterday, and I noticed a few users were hitting the endpoint hundreds of times a second. It’s not a DDoS attack, just a few poorly written scripts, but it's slowing down the app for everyone else. We need a rate limiter.

The memory trap

My first instinct was to just throw a Hash into a Ruby class to keep track of request counts. It seems easy: key the hash by user ID, increment a value, and block them if the value hits a limit. Let's see how that looks.

class SimpleLimiter
  def initialize
    @requests = Hash.new(0)
  end

  def allowed?(user_id)
    @requests[user_id] += 1
    @requests[user_id] <= 5
  end
end

limiter = SimpleLimiter.new
# This works... until it doesn't.

The problem here is obvious once you think about how we actually deploy Ruby apps. We aren't running one single process on one single machine; we have three Puma workers across two different servers. If a user hits Server A, then Server B, their count is split. They get double (or triple) the quota. Plus, if I restart the server, the counts vanish. We need a shared state that lives outside the Ruby process. That's where Redis comes in.

Moving the state to Redis

Since Redis is essentially a giant, networked key-value store, it's perfect for this. I'll swap the Ruby hash for a Redis client. I'll use the INCR command because it's atomic—I don't have to worry about two requests hitting the server at the exact same microsecond and overwriting each other's count.

require 'redis'
$redis = Redis.new

def allowed?(user_id)
  key = "rate_limit:#{user_id}"
  count = $redis.incr(key)
  
  count <= 5
end

I tried this out, and it successfully blocked the user after 5 requests. But then I realized I'd created a permanent ban. Once a user hits 5 requests, they are blocked forever because that key in Redis never goes away. That's a terrible user experience. We need a "window"—usually a minute—after which the count resets.

The expiration glitch

The obvious fix is to use EXPIRE. I'll tell Redis to kill the key after 60 seconds. I'll just tack it onto the end of the method.

def allowed?(user_id)
  key = "rate_limit:#{user_id}"
  count = $redis.incr(key)
  $redis.expire(key, 60) # Reset the window every minute
  
  count <= 5
end

Wait, I just spotted a bug in my own logic. By calling expire on every single request, I'm not creating a fixed 60-second window; I'm creating a sliding window. If a user sends a request every 50 seconds, the key never expires, and they'll eventually hit the limit and stay blocked as long as they keep trying. That's not what I want. I want the window to start on the first request and end 60 seconds later, regardless of subsequent activity.

Locking in the window

To fix this, I only want to set the expiration when the counter is at 1. That means this is the very first request in a new window.

def allowed?(user_id)
  key = "rate_limit:#{user_id}"
  count = $redis.incr(key)
  
  # Only set the timeout on the first request of the window
  $redis.expire(key, 60) if count == 1
  
  count <= 5
end

This is much better. Now, the first request triggers the 60-second countdown. The next four requests increment the counter but don't touch the expiration timer. After 60 seconds, Redis wipes the key, and the user gets a fresh start.

One last thing: in a production environment, there's a tiny "race condition" here. If the server crashes exactly between incr and expire, you'll end up with a key that has no expiration—a permanent ban again. To be truly bulletproof, I'd use a Lua script to make the increment and expiration happen as a single atomic operation inside Redis, but for most internal tools, this logic gets us 99% of the way there.

📋 Practical Task

Build a Per-IP Request Throttler for a Public API

You are tasked with protecting a public-facing API from abuse. Instead of using a User ID (which requires the user to be logged in), you need to build a rate limiter based on the user's IP address.

Create a class called IpRateLimiter that implements the following requirements:

• The class should be initialized with a redis instance and a max_requests limit.
• Implement a method allowed?(ip_address, window_seconds = 60) that returns true if the IP is within the limit and false if they have exceeded it.
• The expiration timer must only be set on the first request of the window to avoid the "sliding window" problem.
• Ensure the Redis keys are namespaced (e.g., "ip_limit:127.0.0.1") so they don't collide with other data in your database.

Testing your code: Try simulating 10 rapid requests from the same IP and verify that only the first max_requests return true.