Hvilke cache-strategier forbedrer en Node API's ydeevne?

Question

Accepted Answer

**Caching** gemmer resultaterne af dyre operationer (databaseforespørgsler, beregninger, eksterne API-kald), så gentagne anmodninger kan betjenes hurtigt uden at gentage arbejdet. Det er en af de højtimpakterende ydeevneoptimeringer for et API.

## In-memory caching (hurtigst, 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;
}
```

Simple og ekstremt hurtigt, men cachen er **per-proces** (ikke delt på tværs af instanser) og går tabt ved genbogstart. God til små, varme data — men kræver eviction (brug en LRU-cache som `lru-cache`) for at begrænse hukommelsen.

## Distribueret 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å tværs af flere serverinstanser — en delt, hurtig lagring, der overlever genbogstart og skalerer med dit app. **TTL** (time-to-live) udløber automatisk poster, så data ikke bliver forældet for evigt.

## HTTP caching (lad 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 aflaster caching til browsere og CDN'er helt — den hurtigste cache er den anmodning, der aldrig når din server.

## Det svære: 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 cache-udfordring er **invalidering** — at sikre, at opdateringer sletter/opdaterer påvirkede cache-poster, så brugerne ikke ser forældede data. Strategier: TTL (accepter kort forældethed), write-through (opdater cache ved skrivning), eller eksplicit sletning ved mutation.

## Hvad der skal caches (og hvad der ikke skal)

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

Caching reducerer dramatisk latency og database-/ekstern belastning, ofte forskellen mellem et langsomt API og et hurtigt, skalérbar API.

At kende lagerne — in-memory (hurtigst, per-instans, begrænset med LRU), Redis (delt på tværs af instanser), og HTTP/CDN-caching (aflast helt) — lader dig vælge den rigtige strategi.

Og at forstå cachings centrale vanskelighed, **invalidering** (via TTL eller eksplicit rydning ved skrivninger), er det, der forhindrer den klassiske fejl i kompromis mellem at serve brugerne forældede data.

Effektiv caching er et af de mest impactfulde værktøjer til API-ydeevne og skalerbarhed.