Welke caching-strategieën verbeteren de prestaties van een Node API?

Question

Accepted Answer

**Caching** slaat de resultaten van dure operaties (databasequery's, berekeningen, externe API-aanroepen) op zodat herhaalde aanvragen snel kunnen worden bediend zonder het werk opnieuw uit te voeren. Het is een van de meest impactvolle prestatieoptimalisaties voor een API.

## In-memory caching (snelst, enkele instantie)

```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;
}
```

Eenvoudig en uiterst snel, maar de cache is **per-proces** (niet gedeeld over instanties heen) en gaat verloren bij herstart. Geschikt voor kleine, hot data — maar vereist evictie (gebruik een LRU-cache zoals `lru-cache`) om het geheugen begrensd te houden.

## Gedistribueerde caching met Redis (gedeeld, schaalbaar)

```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 de standaard voor caching over meerdere serverinstanties — een gedeelde, snelle opslag die herverstarts overleeft en met je app meegroeit. De **TTL** (time-to-live) verloopt items automatisch zodat data niet voor altijd verouderd wordt.

## HTTP caching (laat clients/CDN's cachen)

```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 offloaden caching volledig naar browsers en CDN's — de snelste cache is het verzoek dat nooit je server bereikt.

## Het moeilijke deel: cache-invalidatie

```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
}
```

De grootste caching-uitdaging is **invalidatie** — ervoor zorgen dat updates betrokken cache-entries wissen/vernieuwen zodat gebruikers geen verouderde data zien. Strategieën: TTL (aanvaard korte veroudering), write-through (cache bijwerken bij schrijven), of expliciete verwijdering bij mutatie.

## Wat je moet cachen (en wat niet)

```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
```

## Waarom het belangrijk is

Caching vermindert de latency en database-/externe belasting dramatisch, vaak het verschil tussen een trage API en een snelle, schaalbare. Het kennen van de lagen — in-memory (snelst, per-instantie, begrensd met LRU), Redis (gedeeld over instanties), en HTTP/CDN-caching (volledig offloaden) — stelt je in staat de juiste strategie te kiezen.

En het begrijpen van de centrale moeilijkheid van caching, **invalidatie** (via TTL of expliciete clearing bij schrijvingen), voorkomt het klassieke trade-off-falen van het serveren van verouderde data aan gebruikers.

Effectief caching is een van de meest impactvolle tools voor API-prestaties en schaalbaarheid.