I was building a public API last month when I noticed something alarming - a single client was hammering our authentication endpoint with over 500 requests per second. Our servers started choking, and legitimate users suffered. That’s when I realized: we needed a robust distributed rate limiter that could scale. Today, I’ll show you how I built one with Redis, Express.js, and TypeScript - the same solution that now protects our production systems.

Why focus on distributed systems? Because modern applications run across multiple servers. A local rate limiter won’t prevent coordinated attacks across instances. Think about it - what happens when five servers each allow 100 requests? Suddenly, your API faces 500 requests simultaneously. We need shared state, and Redis delivers exactly that.

Let’s start with algorithm selection. Fixed window is simple but suffers from boundary bursts. Sliding window solves this but consumes more memory. Token bucket offers a sweet spot - it handles bursts naturally while maintaining overall limits. Here’s why it works:

// Token bucket configuration
const rateLimiterConfig = {
  capacity: 10,       // Maximum tokens
  refillRate: 5,       // Tokens per second
  tokensRequested: 1   // Cost per request
};

The bucket refills tokens gradually. When a request arrives, we check if sufficient tokens exist. If yes, we deduct them and allow access. Otherwise, we reject. This elegant model handles short bursts while enforcing long-term averages.

Now, how do we make this distributed? Redis provides atomic operations and shared storage. We’ll use Lua scripting for transactional safety - critical since multiple servers might update the same key simultaneously. Notice the atomic refill-and-check operation:

-- Redis Lua script for token bucket
local tokens = tonumber(redis.call('HGET', KEYS[1], 'tokens'))
local lastRefill = tonumber(redis.call('HGET', KEYS[1], 'lastRefill'))
local capacity = tonumber(ARGV[1])
local refillRate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])

-- Calculate refill
local timeElapsed = math.max(0, now - lastRefill) / 1000
local tokensToAdd = timeElapsed * refillRate
local newTokens = math.min(capacity, (tokens or capacity) + tokensToAdd)

-- Process request
if newTokens >= requested then
  newTokens = newTokens - requested
  redis.call('HMSET', KEYS[1], 'tokens', newTokens, 'lastRefill', now)
  return {1, newTokens} -- Allowed
else
  redis.call('HMSET', KEYS[1], 'tokens', newTokens, 'lastRefill', lastRefill)
  return {0, newTokens} -- Denied
end

This script runs atomically in Redis, eliminating race conditions. But what happens during Redis outages? We implement fallback strategies. For non-critical routes, we might allow all traffic. For sensitive endpoints, we can switch to in-memory limiting or reject requests outright. The key is graceful degradation.

Integrating with Express.js requires middleware. Here’s a TypeScript implementation with proper typing:

// Express middleware implementation
const rateLimiter = (options: RateLimiterOptions) => {
  return async (req: Request, res: Response, next: NextFunction) => {
    const key = generateKey(req, options); // e.g., "user:123"
    
    try {
      const { allowed, tokens } = await tokenBucket.consume(key);
      
      if (allowed) {
        res.set('X-RateLimit-Remaining', tokens.toString());
        next();
      } else {
        const retryAfter = tokenBucket.getRetryAfter(key);
        res.set('Retry-After', retryAfter.toString());
        res.status(429).send('Too Many Requests');
      }
    } catch (error) {
      if (options.fallback === 'allow') next();
      else res.status(503).send('Service Unavailable');
    }
  };
};

Notice the headers? They’re crucial for client cooperation. X-RateLimit-Remaining shows available requests, while Retry-After specifies wait time. This transparency helps developers self-correct.

Now, let’s tackle advanced scenarios. What if you need different limits for free vs. premium users? Or different API endpoints? We extend our key generation:

// Role-based rate limiting
const generateKey = (req: Request, options: RateLimiterOptions) => {
  const userId = req.user.id;
  const role = req.user.role; // 'free' or 'premium'
  
  if (options.byRole) {
    return `rate_limit:${role}:${userId}`;
  }
  return `rate_limit:${userId}`;
};

Premium users might get 100 requests/minute while free users get 10. The same infrastructure supports both through key differentiation.

For production, monitoring is non-negotiable. We track:

• Rejection rates (sudden spikes indicate attacks)
• Redis latency (high values degrade performance)
• Fallback activations (signal Redis issues)

We also implement load tests before deployment. How? Artillery.io scripts simulate thousands of concurrent users:

# artillery-load-test.yml
config:
  target: "https://api.example.com"
  phases:
    - duration: 60
      arrivalRate: 100
scenarios:
  - flow:
      - post:
          url: "/api/protected"
          json:
            data: "test"

This reveals bottlenecks before real users encounter them. Remember to test Redis failure scenarios too - disconnect your Redis instance during tests and verify fallback behavior.

Finally, deployment considerations. Use Redis Cluster for high availability. Set appropriate TTLs on keys to prevent memory bloat. Monitor Redis memory usage and scale accordingly. And always, always implement circuit breakers in your application code.

I’ve seen this implementation handle over 10,000 requests per second with sub-millisecond overhead. It stopped our API from collapsing during a credential stuffing attack last quarter. But technology evolves constantly - what challenges are you facing with rate limiting? Share your experiences in the comments below!

If this guide saved you hours of research, pay it forward. Share with your network to help others build resilient APIs. Got questions or improvements? Let’s discuss - your feedback makes these solutions better for everyone.