0x55aa
← Back to Blog

Node.js + Redis Caching: Stop Hitting Your Database Like It Owes You Money 💸

•5 min read
nodejsrediscachingperformancebackendexpress

Node.js + Redis Caching: Stop Hitting Your Database Like It Owes You Money 💸

Imagine you work at an information desk. Every 10 seconds, someone walks up and asks, "What time does the library close?" You could sprint to the back office, dig through a binder, find the answer (9pm), sprint back, and tell them. Or — and hear me out — you could just remember the answer after the first time.

That's caching in a nutshell. And your Node.js app? It's currently the sprinter. Let's fix that.

Why Your Database Is Suffering in Silence

Every time a user hits /api/products, your app probably:

  1. Parses the request
  2. Authenticates the user
  3. Opens a database connection
  4. Runs a SQL/NoSQL query
  5. Serializes the result
  6. Sends it back

Steps 3–5 are the expensive ones. If 1,000 users hit that endpoint at the same time, you're running 1,000 identical queries. Your database is out here doing the exact same work over and over, quietly weeping.

The data hasn't changed. The query result is the same. You're just... not remembering it.

Enter Redis: Your App's Short-Term Memory

Redis is an in-memory data store — think of it as a ridiculously fast key-value dictionary that lives in RAM. Reading from Redis is 10–100x faster than reading from a traditional database because there's no disk I/O, no query parsing, no join logic. It just looks up a key and hands you the value.

The pattern is simple:

  1. Request comes in
  2. Check Redis first — if the data's there, return it immediately ✅
  3. If not, query the database, store the result in Redis, return it
  4. Next time the same request comes in? Redis answers before your DB even wakes up.

Setting It Up in Node.js

First, install the dependencies:

npm install redis express

Then create a simple caching middleware:

// cache.js
import { createClient } from 'redis';

const client = createClient({ url: process.env.REDIS_URL || 'redis://localhost:6379' });

client.on('error', (err) => console.error('Redis error:', err));
await client.connect();

export function cacheMiddleware(ttlSeconds = 60) {
  return async (req, res, next) => {
    const key = `cache:${req.originalUrl}`;

    const cached = await client.get(key);
    if (cached) {
      console.log(`Cache HIT: ${key}`);
      return res.json(JSON.parse(cached));
    }

    // Intercept res.json to store the response before sending
    const originalJson = res.json.bind(res);
    res.json = async (data) => {
      await client.setEx(key, ttlSeconds, JSON.stringify(data));
      console.log(`Cache SET: ${key} (TTL: ${ttlSeconds}s)`);
      return originalJson(data);
    };

    next();
  };
}

Now plug it into your Express routes:

// app.js
import express from 'express';
import { cacheMiddleware } from './cache.js';
import { getProducts } from './db.js';

const app = express();

// Cache product listings for 5 minutes
app.get('/api/products', cacheMiddleware(300), async (req, res) => {
  const products = await getProducts(); // slow DB call
  res.json(products);
});

app.listen(3000, () => console.log('Server running on port 3000'));

That's it. The first request hits the database; every subsequent request for the next 5 minutes gets served from Redis. Your database just went from 1,000 queries per minute to maybe 1.

The Gotchas (Because Nothing Is Free)

Caching is powerful, but it comes with trade-offs. Here's what will bite you if you're not careful:

Stale data. If a product's price changes, cached responses will still show the old price until the TTL expires. For user-facing data that changes frequently (prices, inventory), use shorter TTLs (10–30 seconds). For rarely-changing data (product categories, config values), longer TTLs (hours or days) are fine.

Cache invalidation. The two hardest problems in computer science are naming things, cache invalidation, and off-by-one errors. When you update a product, you need to explicitly delete its cached entry:

// After updating a product in the DB:
await client.del(`cache:/api/products`);
await client.del(`cache:/api/products/${productId}`);

Memory limits. Redis lives in RAM, which isn't free. Set a maxmemory policy (allkeys-lru is a good default) so Redis evicts old keys instead of crashing when it runs out of space.

Don't cache everything. User-specific data (shopping carts, account details) shouldn't use a shared cache key — or you'll hand one user's cart to another. Either skip caching for personalized routes, or include the user ID in the cache key: cache:/api/cart:${userId}.

When to Use Caching (and When Not To)

Great candidates for caching:

  • Public product/content listings
  • Aggregated stats (daily active users, total orders)
  • Third-party API responses (weather, exchange rates)
  • Expensive computation results

Bad candidates:

  • Anything user-specific without per-user keys
  • Real-time data (live stock prices, chat messages)
  • POST/PUT/DELETE responses (mutations shouldn't be cached)

The Results Are Ridiculous

In a real-world scenario, adding Redis caching to a read-heavy endpoint can drop response times from 200–500ms (database query) to 1–5ms (Redis lookup). That's not a 2x improvement — it's a 100x improvement.

Your users notice sub-5ms responses. They don't notice 200ms ones. But they definitely notice when your API starts timing out because your database is drowning in duplicate queries at peak traffic.

TL;DR

  • Your database is doing redundant work every time you re-fetch unchanged data
  • Redis is a blazing-fast in-memory store perfect for caching API responses
  • A simple Express middleware can cache responses automatically with one line per route
  • Watch out for stale data, cache invalidation, and user-specific data leakage
  • The performance gains are often 50–100x for read-heavy endpoints

Caching isn't premature optimization — it's basic respect for your infrastructure. Start with your most-hit, least-dynamic endpoints, add a 60-second TTL, and watch your database metrics collapse in the best possible way.

Your database will thank you. Silently. Because databases don't talk. But the graphs will speak for themselves. 📉

Have a caching war story or a Redis gotcha that burned you? Drop it in the comments — misery loves company, and horror stories make the best learning material.

← Back to all posts