Caching Strategies

Você atua como engenheiro de performance de dados. Cache troca frescor por velocidade e custo. A parte fácil é guardar; a difícil — e onde moram os bugs — é invalidar. Cacheie com propósito, não por reflexo.

"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton

Quando cachear (e quando não)

Cacheie quando: leitura ≫ escrita, o dado é caro de computar/buscar, e um pouco de staleness é tolerável. Não cacheie quando: o dado muda a cada leitura, precisa ser sempre exato (saldo — ver [[payment-systems]]), ou a taxa de acerto seria baixa (cache frio custa sem ganhar).

Camadas (mais perto do usuário = mais rápido/barato)

Browser (HTTP cache) → CDN (edge) → Cache de app (Redis) → Banco (buffer pool)

Cacheie na camada mais externa que a corretude permite. Um asset estático vai à CDN; uma query cara vai ao Redis; uma resposta por-usuário não vai em camada compartilhada sem chave por usuário.

Padrões de cache

Default pragmático: cache-aside + TTL.

async function getUser(id) {
  const key = `user:${id}`;
  let u = await redis.get(key);
  if (u) return JSON.parse(u);            // hit
  u = await db.users.find(id);            // miss → busca
  await redis.set(key, JSON.stringify(u), 'EX', 300);  // popula com TTL 5min
  return u;
}

Invalidação (o problema difícil)

Três abordagens (combine):

1. TTL / expiração — simples e robusto: aceite dado velho por até N segundos. Escolha o TTL pela tolerância do negócio.
2. Invalidação na escrita — ao atualizar o dado, apague/atualize a chave (redis.del(key)). Preciso, mas exige achar todas as chaves afetadas.
3. Versão/tag na chave — inclua versão no key (user:123:v7); bump da versão invalida em massa sem apagar.

Regra: prefira apagar (del) a atualizar a chave na escrita — mais simples e menos sujeito a corrida.

Cache stampede (thundering herd)

Quando uma chave popular expira, mil requests simultâneos furam para o DB de uma vez. Mitigações: lock/single-flight (só um recomputa, o resto espera), TTL jitter (espalhar expiração), early recompute (renovar antes de expirar), stale-while-revalidate (servir o velho enquanto atualiza em background).

Boas práticas de chave

• Namespace claro: entidade:id:campo (order:42:items).
• Inclua o que muda o resultado (idioma, versão, usuário) na chave — senão serve resposta errada.
• Nunca cacheie dado por-usuário sob chave global.

Recursos externos

Do / Don't

Checklist

• Confirmado leitura ≫ escrita e staleness tolerável
• Padrão escolhido (default: cache-aside + TTL)
• TTL definido pela tolerância do negócio
• Invalidação na escrita (preferir del) + versão/tag quando útil
• Proteção contra stampede em chaves quentes
• Chaves com namespace e todas as dimensões que afetam o resultado
• Nada exato/por-usuário cacheado indevidamente