Ce strategii de caching îmbunătățesc performanța unui API Node?

Question

Accepted Answer

**Caching-ul** stochează rezultatele operațiilor scumpe (interogări BD, calcule, apeluri API externe) pentru ca cererile repetate să poată fi servite rapid fără a reface munca. Este una dintre optimizările de performanță cu cel mai mare impact pentru un API.

## Caching în memorie (cel mai rapid, instanță unică)

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

Simplă și extrem de rapidă, dar cache-ul este **per-proces** (nu este distribuit pe mai multe instanțe) și se pierde la restart. Bună pentru date mici și accesate frecvent — dar necesită evicție (folosiți un cache LRU cum ar fi `lru-cache`) pentru a limita memoria.

## Caching distribuit cu Redis (partajat, scalabil)

```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** este standardul pentru caching pe mai multe instanțe de server — un depozit partajat și rapid care supraviețuiește restarturi și se scalează odată cu aplicația. **TTL**-ul (time-to-live) expirează automat intrările pentru ca datele să nu rămână învechite pentru totdeauna.

## Caching HTTP (permite clienților/CDN-urilor să cache)

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

Anteturile de cache HTTP descarcă caching-ul pe browsere și CDN-uri în totalitate — cel mai rapid cache este cererea care nu ajunge niciodată pe serverul dvs.

## Partea dificilă: invalidarea cache-ului

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

Cea mai mare provocare a caching-ului este **invalidarea** — asigurarea că actualizările șterg/reîmprospătează intrările de cache afectate pentru ca utilizatorii să nu vadă date învechite. Strategii: TTL (acceptă date ușor învechite), write-through (actualizează cache-ul la scriere) sau ștergerea explicită la mutații.

## Ce să cache-uiți (și ce nu)

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

## De ce contează

Caching-ul reduce dramatic latența și încărcarea bazei de date/externă, adesea diferența dintre un API lent și unul rapid și scalabil.

Cunoscând straturile — caching în memorie (cel mai rapid, per-instanță, limitat cu LRU), Redis (partajat pe instanțe) și caching HTTP/CDN (descarcă în totalitate) — vă permite să alegeți strategia corectă.

Și înțelegerea dificultății centrale a caching-ului, **invalidarea** (prin TTL sau ștergere explicită la scrieri), este ceea ce împiedică eșecul clasic al compromisului de a servi utilizatorilor date învechite.

Caching-ul eficient este unul dintre cele mai impactante instrumente pentru performanța și scalabilitatea API-ului.