Quali strategie di caching migliorano le prestazioni di un'API Node?

Question

Accepted Answer

**Caching** memorizza i risultati di operazioni costose (query al database, calcoli, chiamate a API esterne) in modo che le richieste ripetute possano essere servite rapidamente senza ripetere il lavoro. È una delle ottimizzazioni di performance con il maggior impatto per un'API.

## Caching in-memory (più veloce, single-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;
}
```

Semplice e estremamente veloce, ma la cache è **per-processo** (non condivisa tra istanze) e viene persa al riavvio. Ideale per dati piccoli e frequenti — ma richiede eviction (usa una cache LRU come `lru-cache`) per limitare la memoria.

## Caching distribuito con Redis (condiviso, scalabile)

```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** è lo standard per il caching su più istanze di server — uno storage condiviso e veloce che sopravvive ai riavvii e scala con la tua app. Il **TTL** (time-to-live) scade automaticamente le entry in modo che i dati non rimangono obsoleti indefinitamente.

## Caching HTTP (lascia che client/CDN facciano il caching)

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

Gli header di caching HTTP delegano completamente il caching a browser e CDN — la cache più veloce è la richiesta che non raggiunge mai il tuo server.

## La parte difficile: invalidazione della cache

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

La maggiore sfida del caching è l'**invalidazione** — assicurarsi che gli aggiornamenti eliminino/aggiornino le entry di cache interessate in modo che gli utenti non vedano dati obsoleti. Strategie: TTL (accetta breve obsolescenza), write-through (aggiorna la cache in scrittura), o cancellazione esplicita su mutazione.

## Cosa cachare (e cosa no)

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

## Perché è importante

Il caching riduce drasticamente la latenza e il carico su database/servizi esterni, spesso è la differenza tra un'API lenta e una veloce e scalabile.

Conoscere i livelli — caching in-memory (più veloce, per-istanza, limitato con LRU), Redis (condiviso tra istanze) e caching HTTP/CDN (delega completamente) — ti consente di scegliere la giusta strategia.

E comprendere la difficoltà centrale del caching, l'**invalidazione** (tramite TTL o cancellazione esplicita in scrittura), è ciò che previene il classico fallimento del trade-off di servire agli utenti dati obsoleti.

Il caching efficace è uno dei strumenti più impattanti per le prestazioni e la scalabilità dell'API.