¿Qué estrategias de caché mejoran el rendimiento de una API en Node?

Question

Accepted Answer

El **caching** almacena los resultados de operaciones costosas (consultas a la BD, cómputos, llamadas a APIs externas) para que las solicitudes repetidas se puedan atender rápido sin rehacer el trabajo. Es una de las optimizaciones de rendimiento de mayor impacto para una API.

## Caché en memoria (la más rápida, una sola instancia)

```js
const cache = new Map();

async function getUser(id) {
  if (cache.has(id)) return cache.get(id); // ACIERTO de caché — instantáneo
  const user = await db.findUser(id);       // FALLO de caché — hace el trabajo
  cache.set(id, user);
  return user;
}
```

Simple y extremadamente rápida, pero la caché es **por proceso** (no se comparte entre instancias) y se pierde al reiniciar. Buena para datos pequeños y muy consultados — pero necesita desalojo (usa una caché LRU como `lru-cache`) para acotar la memoria.

## Caché distribuida con Redis (compartida, escalable)

```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);          // acierto

const user = await db.findUser(id);
  await redis.setEx(`user:${id}`, 3600, JSON.stringify(user)); // cachea por 1h (TTL)
  return user;
}
```

**Redis** es el estándar para cachear entre múltiples instancias de servidor — un almacén compartido y rápido que sobrevive a los reinicios y escala con tu app. El **TTL** (time-to-live, tiempo de vida) expira las entradas automáticamente para que los datos no queden obsoletos para siempre.

## Caché HTTP (deja que clientes/CDNs cacheen)

```js
res.set("Cache-Control", "public, max-age=3600"); // los navegadores/CDN cachean por 1h
res.set("ETag", hash);                            // solicitudes condicionales (304 Not Modified)
```

Los encabezados de caché HTTP delegan el caching enteramente a los navegadores y CDNs — la caché más rápida es la solicitud que nunca llega a tu servidor.

## La parte difícil: la invalidación de la caché

```js
// cuando los datos cambian, la caché debe actualizarse o limpiarse, o los usuarios verán datos obsoletos
async function updateUser(id, data) {
  await db.updateUser(id, data);
  await redis.del(`user:${id}`); // INVALIDA — la próxima lectura la repuebla con datos frescos
}
```

El mayor desafío del caching es la **invalidación** — asegurar que las actualizaciones limpien/refresquen las entradas de caché afectadas para que los usuarios no vean datos obsoletos. Estrategias: TTL (acepta una breve obsolescencia), write-through (actualiza la caché al escribir) o eliminación explícita ante una mutación.

## Qué cachear (y qué no)

```text
✓ Datos de mucha lectura y que cambian con poca frecuencia (config, catálogos de productos, perfiles de usuario)
✓ Cómputos costosos, respuestas de APIs externas
✗ Datos altamente dinámicos/personalizados o que cambian rápidamente (o usa TTLs muy cortos)
✗ Datos sensibles sin cuidado sobre quién puede leer la caché
```

## Por qué es importante

El caching reduce drásticamente la latencia y la carga sobre la base de datos/los servicios externos, a menudo la diferencia entre una API lenta y una rápida y escalable.

Conocer las capas — en memoria (la más rápida, por instancia, acotada con LRU), Redis (compartida entre instancias) y caché HTTP/CDN (delegación total) — te permite elegir la estrategia correcta.

Y entender la dificultad central del caching, la **invalidación** (mediante TTL o limpieza explícita en las escrituras), es lo que previene la falla clásica del compromiso: servir datos obsoletos a los usuarios.

Un caching efectivo es una de las herramientas de mayor impacto para el rendimiento y la escalabilidad de una API.