Quais estratégias de cache melhoram o desempenho de uma API Node?

Question

Accepted Answer

**Cache** armazena os resultados de operações caras (consultas de banco de dados, computações, chamadas de API externa) para que solicitações repetidas possam ser servidas rapidamente sem refazer o trabalho. É uma das otimizações de desempenho de maior impacto para uma API.

## Cache em memória (mais rápido, instância única)

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

Simples e extremamente rápido, mas o cache é **por processo** (não compartilhado entre instâncias) e perdido no reinício. Bom para dados pequenos e quentes — mas precisa de evicção (use um cache LRU como `lru-cache`) para delimitar a memória.

## Cache distribuído com Redis (compartilhado, escalável)

```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** é o padrão para cache em múltiplas instâncias de servidor — um armazenamento compartilhado e rápido que sobrevive a reinícios e escala com sua aplicação. O **TTL** (time-to-live) expira automaticamente as entradas para que os dados não fiquem desatualizados para sempre.

## Cache HTTP (deixar clientes/CDNs fazer cache)

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

Os cabeçalhos de cache HTTP descarregam o cache para navegadores e CDNs inteiramente — o cache mais rápido é a solicitação que nunca chega ao seu servidor.

## A parte difícil: invalidação de 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
}
```

O maior desafio de cache é **invalidação** — garantir que atualizações limpem/atualizem as entradas de cache afetadas para que os usuários não vejam dados desatualizados. Estratégias: TTL (aceitar breve desatualização), write-through (atualizar cache na escrita) ou exclusão explícita em mutações.

## O que fazer cache (e o que não fazer)

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

## Por que isso importa

O cache reduz dramaticamente a latência e a carga do banco de dados/externa, frequentemente a diferença entre uma API lenta e uma rápida e escalável.

Conhecer as camadas — cache em memória (mais rápido, por instância, delimitado com LRU), Redis (compartilhado entre instâncias) e cache HTTP/CDN (descarregue inteiramente) — permite escolher a estratégia certa.

E entender a dificuldade central do cache, **invalidação** (via TTL ou limpeza explícita em escritas), é o que evita a falha clássica de compromisso de servir dados desatualizados aos usuários.

O cache eficaz é uma das ferramentas mais impactantes para desempenho e escalabilidade de API.