Vilka cachestrategier förbättrar prestandan på ett Node API?

Question

Accepted Answer

**Caching** lagrar resultaten från dyra operationer (databasfrågor, beräkningar, externa API-anrop) så att upprepade förfrågningar kan servas snabbt utan att göra om arbetet. Det är en av de högsta resultatoptimeringarna för ett API.

## In-memory caching (snabbast, enkel 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 och extremt snabbt, men cachen är **per-process** (inte delad mellan instanser) och går förlorad vid omstart. Bra för små, ofta använda data — men behöver eviction (använd en LRU-cache som `lru-cache`) för att begränsa minnet.

## Distribuerad caching med Redis (delad, skalbar)

```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** är standarden för caching över flera serverinstanser — ett delat, snabbt lager som överlever omstarter och skalas med din app. **TTL** (time-to-live) upphävs automatiskt poster så data inte blir föråldrad för alltid.

## HTTP caching (låt klienter/CDN-nätverk cacha)

```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 avlastar caching till webbläsare och CDN-nätverk helt — den snabbaste cachen är förfrågan som aldrig når din server.

## Det svåra: 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
}
```

Det största cacheproblem är **invalidering** — att säkerställa att uppdateringar rensar/uppdaterar påverkade cache-poster så att användare inte ser föråldrad data. Strategier: TTL (acceptera kort föråldring), write-through (uppdatera cache vid skrivning), eller explicit borttagning vid mutation.

## Vad som ska cachas (och inte)

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

## Varför det är viktigt

Caching minskar latensen och databas-/externt värdelaster dramatiskt, ofta skillnaden mellan ett långsamt API och ett snabbt, skalbart.

Att känna till lagren — in-memory (snabbast, per-instans, begränsad med LRU), Redis (delat mellan instanser) och HTTP/CDN caching (avlasta helt) — låter dig välja rätt strategi.

Och att förstå cachings centrala svårighet, **invalidering** (via TTL eller explicit rensning vid skrivningar), är det som förhindrar det klassiska misslyckandet av att servera användare föråldrad data.

Effektiv caching är ett av de mest effektfulla verktygen för API-prestanda och skalbarhet.