How would you implement caching in a Node.js application?

Q: How would you implement caching in a Node.js application?

**Target Audience:** Engineers preparing for Node.js system-design interviews — assumes familiarity with the performance-techniques question's real cache-timing proof. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The TTL expiration below was **actually observed** — a real 150ms wait, a real check against the elapsed time, not an assumption that expiration "should" work. ## 1. Why This Even Matters — A Story First A whiteboard note reading "meeting moved to 3pm" is genuinely useful information — right up until the meeting time changes again and nobody erases the old note. Anyone glancing at that whiteboard later trusts a note that quietly stopped being true. A cache with no expiration or invalidation plan is exactly that whiteboard: fast to read, and silently wrong the moment the underlying truth moves on without it. ## 2. The Core Idea 📌 **Interview term:** caching stores an ex

The problem

Question presented to candidate: "You cache a user's profile data to avoid a repeated database query, but the user updates their profile five minutes later. How does your cache avoid serving the old, now-wrong data forever?"

What a strong answer should cover:

Caching stores an expensive-to-compute or expensive-to-fetch result, keyed by its input, so a repeated request for the identical input can be served from memory instead of redoing the work — verified with real measured timing (an identical computation dropping from 104ms to 0ms) in the dedicated performance-techniques question.
📌 The core problem the prompt's scenario raises, and its standard fix: a cache with no expiration or invalidation strategy will happily serve stale data forever. A TTL (time-to-live) is the simplest fix — verified directly: a cached value read correctly immediately after being set, and the identical key read again after its TTL had genuinely elapsed correctly returned nothing, forcing a fresh fetch.
Beyond a blind TTL, explicit invalidation (deleting or updating the cached entry the moment the underlying data actually changes — e.g. when the profile update itself is saved) is more precise than waiting out a TTL, at the cost of needing to remember to invalidate at every single write path that could make the cached value stale.
Where the cache lives matters for correctness at scale: an in-process cache (a plain Map) is fastest but is not shared across multiple processes/instances (covered in the dedicated clustering question, with real proof that each worker process has genuinely separate memory) — a shared external cache (Redis) is required when multiple processes/instances must see the same cached state consistently.
A precise answer distinguishes cache-aside (the application checks the cache, falls back to the source on a miss, then populates the cache — the pattern demonstrated directly here) from a write-through cache (updated proactively at write time, alongside the source of truth) — genuinely different strategies for keeping the cache correct, not interchangeable details.
The honest trade-off, stated explicitly: caching trades some staleness risk for speed — the right TTL/invalidation strategy depends entirely on how tolerable a temporarily-stale value actually is for that specific piece of data, which is a product/business decision as much as a technical one.

Clarifying questions expected:

"How tolerable is briefly-stale data for this specific value — seconds, minutes, or never?" — directly decides the TTL/invalidation strategy.
"Does this cache need to be consistent across multiple processes/instances, or is in-process sufficient?" — decides between a local Map and an external store like Redis.

Code / implementation expected: Yes — a real TTL-based cache, verified actually expiring a value after its real elapsed time, is the concrete, convincing demonstration of the prompt's exact staleness concern being handled correctly.

caching
performance
redis
optimization

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for Node.js system-design interviews — assumes familiarity with the performance-techniques question's real cache-timing proof. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The TTL expiration below was actually observed — a real 150ms wait, a real check against the elapsed time, not an assumption that expiration "should" work.

1. Why This Even Matters — A Story First

A whiteboard note reading "meeting moved to 3pm" is genuinely useful information — right up until the meeting time changes again and nobody erases the old note. Anyone glancing at that whiteboard later trusts a note that quietly stopped being true. A cache with no expiration or invalidation plan is exactly that whiteboard: fast to read, and silently wrong the moment the underlying truth

The solution is hidden so you can try first

6 min read · 9 sections

Read the code

JavaScriptA real TTL-based cache: correct read before expiration, genuinely empty after the real TTL elapses

class TTLCache {
  constructor() { this.store = new Map(); }
  set(key, value, ttlMs) {
    this.store.set(key, { value, expiresAt: Date.now() + ttlMs });
  }
  get(key) {
    const entry = this.store.get(key);
    if (!entry) return undefined;
    if (Date.now() > entry.expiresAt) { this.store.delete(key); return undefined; }
    return entry.value;
  }
}

const cache = new TTLCache();
cache.set("user:1", { name: "Ada" }, 100); // 100ms TTL

console.log(cache.get("user:1")); // { name: 'Ada' } — immediately after set

setTimeout(() => {
  console.log(cache.get("user:1")); // undefined — genuinely expired, forces a fresh fetch
}, 150);

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.