What caching strategies improve a Node API's performance?

Question

Accepted Answer

**Caching** stores the results of expensive operations (DB queries, computations, external API calls) so repeated requests can be served fast without redoing the work. It's one of the highest-impact performance optimizations for an API.

## In-memory caching (fastest, single-instance)

```js
const cache = new Map();

async function getUser(id) {
  if (cache.has(id)) return cache.get(id); // cache HIT — instant
  const user = await db.findUser(id);       // cache MISS — do the work
  cache.set(id, user);
  return user;
}
```

Simple and extremely fast, but the cache is **per-process** (not shared across instances) and lost on restart. Good for small, hot data — but needs eviction (use an LRU cache like `lru-cache`) to bound memory.

## Distributed caching with Redis (shared, scalable)

```js
import { createClient } from "redis";
const redis = createClient();

async function getUser(id) {
  const cached = await redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);          // hit

const user = await db.findUser(id);
  await redis.setEx(`user:${id}`, 3600, JSON.stringify(user)); // cache for 1h (TTL)
  return user;
}
```

**Redis** is the standard for caching across multiple server instances — a shared, fast store that survives restarts and scales with your app. The **TTL** (time-to-live) auto-expires entries so data doesn't go stale forever.

## HTTP caching (let clients/CDNs cache)

```js
res.set("Cache-Control", "public, max-age=3600"); // browsers/CDN cache for 1h
res.set("ETag", hash);                            // conditional requests (304 Not Modified)
```

HTTP cache headers offload caching to browsers and CDNs entirely — the fastest cache is the request that never reaches your server.

## The hard part: cache invalidation

```js
// when data changes, the cache must be updated or cleared, or users see stale data
async function updateUser(id, data) {
  await db.updateUser(id, data);
  await redis.del(`user:${id}`); // INVALIDATE — next read repopulates with fresh data
}
```

The biggest caching challenge is **invalidation** — ensuring updates clear/refresh affected cache entries so users don't see stale data. Strategies: TTL (accept brief staleness), write-through (update cache on write), or explicit deletion on mutation.

## What to cache (and not)

```text
✓ Read-heavy, infrequently-changing data (config, product catalogs, user profiles)
✓ Expensive computations, external API responses
✗ Highly dynamic/personalized or rapidly-changing data (or use very short TTLs)
✗ Sensitive data without care for who can read the cache
```

## Why it matters

Caching dramatically reduces latency and database/external load, often the difference between a slow API and a fast, scalable one.

Knowing the layers — in-memory (fastest, per-instance, bounded with LRU), Redis (shared across instances), and HTTP/CDN caching (offload entirely) — lets you pick the right strategy.

And understanding caching's central difficulty, **invalidation** (via TTL or explicit clearing on writes), is what prevents the classic trade-off failure of serving users stale data.

Effective caching is one of the most impactful tools for API performance and scalability.