Back to Blog
tutorialFebruary 4, 20265 min read

Build a Rate Limiter for Your Node.js API in 5 Minutes

You've built an amazing API. Users love it. But then someone decides to hammer your endpoints with thousands of requests per second, and suddenly your server is on fire. Sound familiar?

Rate limiting isn't just a nice-to-have—it's essential for any production API. In this tutorial, I'll show you how to build a proper rate limiter using Redis in just a few minutes. No complex libraries, no black boxes—just clean, understandable code.

Why Your API Needs Rate Limiting

Without rate limiting, you're essentially leaving your front door wide open. Here's what can happen:

  • Cost explosion — One bad actor can 10x your infrastructure costs overnight
  • Performance degradation — Legitimate users suffer while bots feast
  • Security vulnerabilities — Brute force attacks become trivially easy

The good news

A well-implemented rate limiter takes about 20 lines of code and solves all these problems.

The Sliding Window Algorithm

We'll use the sliding window algorithm because it's smoother than fixed windows. Instead of resetting counts at the start of each minute, we look at a rolling window of time.

Here's the core implementation:

async function rateLimit(key, limit, windowMs) {
  const now = Date.now()
  const window = Math.floor(now / windowMs)
  const redisKey = `rate:${key}:${window}`
  
  const count = await redis.incr(redisKey)
  await redis.expire(redisKey, windowMs / 1000 * 2)
  
  return count <= limit
}

That's the core idea—we increment a counter for the current time window and check if it exceeds our limit. But let's make it production-ready.

Express Middleware

Here's how you'd use it in a real Express app:

app.use(async (req, res, next) => {
  const key = req.ip
  const allowed = await rateLimit(key, 100, 60000)
  
  if (!allowed) {
    return res.status(429).json({ 
      error: 'Too many requests' 
    })
  }
  next()
})

Pro tip

Use different limits for different endpoints. Authentication endpoints should have much stricter limits than read-only endpoints.

Taking It Further

Once you have the basics working, consider these improvements:

  • Higher limits for authenticated users
  • Separate limits per API key for B2B customers
  • Graceful degradation when Redis is unavailable
  • Rate limit headers (X-RateLimit-Remaining)

Rate limiting is one of those things that seems simple but makes a huge difference in production. Your future self (and your ops team) will thank you.

Ready to build something amazing?

Get your Redis database running in 30 seconds. No credit card required.

Start Free →