Milyen caching stratégiák javítják egy Node API teljesítményét?

Question

Accepted Answer

**Caching** tárolja a költséges műveletek (adatbázis lekérdezések, számítások, külső API hívások) eredményeit, így az ismételt kérések gyorsan kiszolgálhatók anélkül, hogy újra kellene elvégezni a munkát. Ez az egyik legmagasabb hatásúteljesítmény-optimalizálás egy API-hoz.

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

Egyszerű és rendkívül gyors, de a cache **folyamatonként** működik (nem osztott meg az instancek között) és az újraindítás során elvész. Jó kis, gyakran használt adatokhoz — de szükség van kiürítésre (használj egy LRU cache-t, mint a `lru-cache`) a memória korlátozott maradása érdekében.

## Distributed caching Redis-szel (megosztott, skálázható)

```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** az ipari standard a caching-hez több szerver instance között — egy megosztott, gyors tár, amely túléli az újraindításokat és az alkalmazásod számára skálázódik. A **TTL** (time-to-live) automatikusan lejárják az entry-ket, így az adatok nem maradnak örökké elavultak.

## HTTP caching (hagyj az ügyfeleknek/CDN-eknek cache-elni)

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

A HTTP cache fejlécek teljes egészében az böngészőkre és CDN-ekre bízza a caching-et — a leggyorsabb cache az a kérés, amely soha nem éri el a szerveredet.

## A nehéz rész: cache invalidáció

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

A caching legnagyobb kihívása az **invalidáció** — biztosítani, hogy a frissítések töröljék/frissítsék az érintett cache entry-ket, hogy a felhasználók ne lássanak elavult adatokat. Stratégiák: TTL (fogadd el a rövid ideig elavult adatokat), write-through (frissítsd a cache-t az íráskor), vagy explicit törlés mutáció során.

## Mit érdemes cache-elni (és mit nem)

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

## Miért számít

A caching drámaian csökkenti a latenciát és az adatbázis/külső terhelést, gyakran a különbség egy lassú API és egy gyors, skálázható között.

A rétegek ismerete — in-memory (leggyorsabb, instance-onként, LRU-val korlátozott), Redis (megosztott instancek között), és HTTP/CDN caching (teljes kihelyezés) — lehetővé teszi az adekvát stratégia kiválasztását.

És a caching központi nehézségének megértése, az **invalidáció** (TTL vagy explicit törlés az írások során), az, amely megelőzi a klasszikus trade-off kudarcot az elavult adatok felhasználók számára történő kiszolgálásának.

A hatékony caching az API teljesítmény és skálázhatóság egyik legtöbb hatással járó eszköze.