Hvilke cache-strategier forbedrer ytelsen til en Node API?

Question

Accepted Answer

**Caching** lagrer resultatene fra dyre operasjoner (databasespørringer, beregninger, eksterne API-kall) slik at gjentatte forespørsler kan betjenes raskt uten å gjøre arbeidet på nytt. Det er en av de høyeste-impact ytelsesoptimaliseringene for et API.

## In-memory caching (raskest, enkelt instans)

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

Enkelt og ekstremt raskt, men cache er **per-prosess** (ikke delt på tvers av instanser) og går tapt ved omstart. Bra for små, varme data — men trenger eviction (bruk en LRU cache som `lru-cache`) for å begrense minne.

## Distribuert caching med Redis (delt, skalerbar)

```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** er standarden for caching på tvers av flere serverinstanser — en delt, rask lagring som overlever omstarter og skaleres med appen din. **TTL** (time-to-live) utløper oppføringer automatisk slik at data ikke blir foreldet for alltid.

## HTTP caching (la klienter/CDN-er 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-headere offloader caching til nettlesere og CDN-er helt — den raskeste cache er forespørselen som aldri når serveren din.

## Den vanskelige delen: cache-invalidering

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

Den største caching-utfordringen er **invalidering** — å sikre at oppdateringer sletter/oppfrisker berørte cache-oppføringer slik at brukere ikke ser gamle data. Strategier: TTL (aksepter kort foreldelse), write-through (oppdater cache ved skriving), eller eksplisitt sletting på mutasjon.

## Hva du skal cache (og ikke)

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

## Hvorfor det er viktig

Caching reduserer dramatisk latens og database/ekstern belastning, ofte forskjellen mellom et tregt API og et raskt, skalerbart. Å kjenne lagene — in-memory (raskest, per-instans, begrenset med LRU), Redis (delt på tvers av instanser), og HTTP/CDN caching (offloader helt) — lar deg velge riktig strategi.

Og å forstå cachings sentrale vanskelighet, **invalidering** (via TTL eller eksplisitt clearing ved skriving), er det som forhindrer det klassiske trade-off-fiaskoen med å vise brukere gamle data.

Effektiv caching er ett av de mest impactfulle verktøyene for API-ytelse og skalerbarhet.