Redis Caching Patterns Every MERN Developer Should Know

I added Redis to both Linkite and NeoGPT, and each time I learned something new about when and how to cache. These are the patterns I wish I'd read before I started — explained with actual code from my projects, not toy examples.

Cache-aside (lazy loading)

Cache-aside is the pattern you reach for most often. The application checks the cache before hitting the database. On a miss, it reads from the database and writes the result to the cache. Simple, effective, and easy to reason about.

// classic cache-aside — what I use in Linkite for URL resolution
async function getLink(shortId) {
  const key = `link:${shortId}`;

  // try cache first
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  // not in cache — go to DB
  const link = await db.links.findOne({ shortId });
  if (!link) return null;

  // store in cache for next time, expire in 24 hours
  await redis.setex(key, 86400, JSON.stringify(link));
  return link;
}

Write-through

Write-through keeps the cache in sync with every write. When you update the database, you also update the cache. More writes, but you never serve stale data. I use this in NeoGPT for thread objects — when a new message comes in, I update MongoDB and the Redis cache at the same time.

async function appendMessage(threadId, message) {
  // update MongoDB
  await db.threads.updateOne(
    { threadId },
    { $push: { messages: message }, $set: { updatedAt: new Date() } }
  );

  // update Redis cache immediately — no stale reads
  const thread = await db.threads.findOne({ threadId });
  await redis.setex(`thread:${threadId}`, 3600, JSON.stringify(thread));
}

TTL strategy — not all data ages equally

One mistake I made early on: giving everything the same TTL. A URL that gets clicked 1000 times a day deserves a much longer TTL than one that was created and never touched again. Think about access patterns when you set TTLs:

• ›Short-lived sessions (auth tokens): 15–60 minutes
• ›User profile data: 1–6 hours
• ›URL redirect targets: 24 hours (they rarely change)
• ›Chat thread context: 1 hour after last message
• ›Analytics aggregates: 5–15 minutes

Eviction policies

Redis has several eviction policies that kick in when memory is full. The one I recommend for most MERN apps is allkeys-lru — evict the least recently used key from anywhere. It means your hottest data stays in cache automatically without you having to manually manage what to keep.

Set it in your Redis config with: maxmemory-policy allkeys-lru. And always set a maxmemory limit — without it, Redis will happily eat all available RAM.

One thing to watch out for: cache stampede

If a cached item expires and you get a burst of requests at that exact moment, all of them will miss the cache, all go to the DB simultaneously, and suddenly your database is handling 50 concurrent identical queries. This is called a cache stampede.

The simplest fix: jitter your TTLs. Instead of setex(key, 3600, value), use setex(key, 3600 + Math.random() * 300, value). Stagger expirations so not everything expires at once. For high-traffic keys, you can also implement a 'lock' pattern where only one process regenerates the cache while others serve the stale value.

Final thought

Caching is one of those things where a little bit goes a long way. Even a simple cache-aside layer in front of MongoDB makes a measurable difference in response times. Start simple, measure, then tune your TTLs and patterns based on real access data.