The Stack at a Glance

The project is a URL shortener built with:

• Node.js + Express for the API
• express-rate-limit v8.3.0+ for rate limiting
• Redis for URL caching (not rate limiting — more on that later)
• .env-based config for tunable limits per environment

Where the Values Come From

Good configuration is never hardcoded in the middleware itself. In this project, rate limit values flow through a clean three-step chain.

Step 1 — Environment Variables (.env)

RATE_LIMIT_WINDOW_MS=900000       # 15 minutes in milliseconds
RATE_LIMIT_MAX_REQUESTS=100       # max 100 requests per window

Keeping these in .env means you can tighten limits in production and relax them in development — without touching code.

Step 2 — src/config/env.js

app: {
  baseUrl: process.env.BASE_URL || 'http://localhost:3000',
  rateLimitWindowMs:    parseInt(process.env.RATE_LIMIT_WINDOW_MS, 10)    || 900000,
  rateLimitMaxRequests: parseInt(process.env.RATE_LIMIT_MAX_REQUESTS, 10) || 100
}

Two things to notice here:

1. parseInt(..., 10) — env vars are always strings. Forgetting to parse them is a classic bug that produces NaN comparisons.
2. Fallback defaults — if the env var is missing, the app still works sensibly. 900000 ms = 15 minutes and 100 requests are reasonable defaults.

This config object becomes the single source of truth for all app settings.

Step 3 — src/middleware/rateLimiter.js

const config = require('../config/env');

const apiLimiter = rateLimit({
  windowMs: config.app.rateLimitWindowMs,
  max:      config.app.rateLimitMaxRequests,
  // ...
});

The middleware consumes config — it never defines magic numbers itself. Clean.

Two Limiters, Two Purposes

One of the more thoughtful design choices in this project is having two separate rate limiters rather than one global one.

apiLimiter — General API Protection

const apiLimiter = rateLimit({
  windowMs: config.app.rateLimitWindowMs,    // 15 min (from env)
  max:      config.app.rateLimitMaxRequests, // 100 requests (from env)
  message: {
    success: false,
    error: 'Too many requests, please try again later'
  },
  standardHeaders: true,   // Sends RateLimit-* headers (RFC 6585)
  legacyHeaders: false,    // Suppresses old X-RateLimit-* headers
});

Setting standardHeaders: true is important for API consumers. It lets them inspect headers and back off gracefully before hitting the limit.

createLimiter — Stricter Protection for URL Creation

const createLimiter = rateLimit({
  windowMs: 60 * 60 * 1000, // 1 hour (hardcoded)
  max: 20,                  // 20 URL creations per hour per IP
  message: {
    success: false,
    error: 'Too many URLs created, please try again in an hour'
  },
  standardHeaders: true,
  legacyHeaders: false,
});

Why a separate limiter for creation?

Creating short URLs is a write operation. Without a dedicated stricter limit, a bad actor could spend their entire 100-request general budget creating spam links. By adding an independent createLimiter, you enforce a hard cap of 20 new URLs per hour — regardless of how many other API calls that IP makes. The limits operate independently.

Wiring It All Together — Middleware Order Matters

This is where things get interesting. The order of middleware registration in src/app.js is not accidental:

// ① Trust proxy — must come first
app.set('trust proxy', 1);

// ② General rate limit on ALL /api/* routes
app.use('/api', apiLimiter, apiRoutes);

// ③ Additional stricter limit specifically on POST /api/shorten
app.post('/api/shorten', createLimiter);

// ④ Redirect routes — intentionally NO rate limiter
app.use('/', redirectRoutes);

The Double-Limiter on POST /api/shorten

Because apiLimiter is applied to all /api/* routes and createLimiter is registered specifically for POST /api/shorten, that single endpoint is protected by both limiters in sequence:

Incoming: POST /api/shorten
          │
          ▼
    apiLimiter
    (100 req / 15 min per IP)
          │ pass
          ▼
    createLimiter
    (20 req / 1 hour per IP)
          │ pass
          ▼
    Route handler runs

A request must clear both checks. This is a composable, layered approach — adding protection at creation without dismantling the general API guard.

Why Redirects Have No Rate Limiter

// Redirect routes (no rate limiting on redirects - we want them fast)
app.use('/', redirectRoutes);

This is a deliberate design decision and a good one. The /:shortCode → original URL redirect is the hot path — every click on a short link hits it. Adding a rate-limit middleware check here would introduce latency on every redirect. Since redirects are read-only and don't mutate state, the risk/benefit trade-off favors keeping them unrestricted.

The trust proxy Setting — Critical for Correctness

app.set('trust proxy', 1);

This tiny line is critical. Here's why.

express-rate-limit identifies clients by their IP address. By default, Express reads req.socket.remoteAddress. But in nearly any real deployment — behind Nginx, a load balancer, Docker networking, or a cloud provider's reverse proxy — that address is always the proxy's IP, not the real client's.

Setting trust proxy = 1 instructs Express to trust the X-Forwarded-For header injected by the first upstream proxy, so the rate limiter tracks the actual user's IP.

Without this:

• Everyone hitting your API appears to come from the same IP address (the proxy)
• All users share a single rate limit counter
• The limiter becomes effectively useless

The 1 means "trust one proxy hop." If you have multiple proxy layers, adjust accordingly.

What Happens When the Limit Is Hit

When a client exceeds a limit, express-rate-limit short-circuits the middleware chain and immediately responds:

HTTP 429 Too Many Requests

{
  "success": false,
  "error": "Too many requests, please try again later"
}

Or, specifically for URL creation:

{
  "success": false,
  "error": "Too many URLs created, please try again in an hour"
}

Because standardHeaders: true is set, the response also includes:

RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: <unix timestamp>

Well-behaved clients can read these headers and implement exponential backoff or a cooldown timer.

Storage: In-Memory (and Its Trade-offs)

The default store for express-rate-limit is an in-memory Map inside the Node process:

{
  "203.0.113.42": { count: 47, resetTime: 1712519200000 },
  "198.51.100.1":  { count: 99, resetTime: 1712519200000 },
}

Pros:

• Zero configuration
• Zero external dependency
• Near-zero latency

Cons:

• State is lost on server restart — all counters reset
• Not shared across multiple instances — if you run 3 Node processes behind a load balancer, a client can make 100 × 3 = 300 requests by hitting each instance

Note: This project has Redis configured in src/config/redis.js and redis in its dependencies — but Redis is used exclusively for URL caching, not rate limiting. To make rate limiting work correctly across multiple instances, you'd integrate a package like rate-limit-redis and pass it as the store option to rateLimit(). For a single-instance deployment, the in-memory default is perfectly fine.

Complete Request Flow

Here's the full picture from client request to response:

Client Request
      │
      ▼
trust proxy → Real IP extracted from X-Forwarded-For
      │
      ▼
Is path /api/* ?
  ├── YES → apiLimiter
  │           IP count < 100 in last 15 min? → pass
  │           IP count ≥ 100?               → HTTP 429
  │                │ (passed)
  │                ▼
  │          Is it POST /api/shorten?
  │            ├── YES → createLimiter
  │            │           IP count < 20 in last 1 hour? → pass
  │            │           IP count ≥ 20?                → HTTP 429
  │            │                │ (passed)
  │            │                ▼
  │            │           Route handler runs
  │            └── NO  → Route handler runs
  └── NO → Is path /:shortCode?
             └── No rate limiting → Redirect handler runs

Summary Table

Key Takeaways

• Use environment variables for rate limit values so you can tune them per environment without code changes.
• Don't rely on a single global limiter — write operations deserve their own stricter, independent limits.
• trust proxy is not optional in any real deployment; without it, your limiter is measuring the wrong IP.
• standardHeaders: true gives API clients the information they need to back off gracefully.
• In-memory storage works for single-instance apps, but switch to a shared store (Redis) before scaling horizontally.
• Deliberate omissions matter — choosing not to rate-limit redirects is a valid performance decision, not an oversight.

Have questions about rate limiting strategies or scaling beyond a single Node instance? Drop a comment below!