Pergunte para que serve o Redis e a resposta vem no reflexo: "cache". Verdade, e é como apresentar um canivete suíço dizendo que ele corta barbante. O Redis é um servidor de estruturas de dados em memória (redis.io): listas, conjuntos, hashes, rankings e streams com latência de microssegundos. O cache é só o primeiro truque.

O truque nº 1, bem feito: cache

Já que é o mais comum, que seja correto. O padrão cache-aside em Node:

async function getProduto(id) {
  const cacheKey = `produto:${id}`;
  const emCache = await redis.get(cacheKey);
  if (emCache) return JSON.parse(emCache);

  const produto = await db.produto.findUnique({ where: { id } });
  await redis.set(cacheKey, JSON.stringify(produto), "EX", 300); // TTL: 5 min
  return produto;
}

As três regras que separam cache profissional de bomba-relógio:

1. Todo cache tem TTL. Chave sem expiração é vazamento de memória com data marcada e dado velho para sempre.
2. Invalide na escrita: atualizou o produto, DEL produto:42. TTL é a rede de segurança, não a estratégia.
3. Cuidado com a debandada (cache stampede): a chave quente expira e mil requisições atacam o banco juntas. Mitigações: TTL com variação aleatória e trava para só uma requisição reconstruir.

Os outros truques do canivete

Rate limiting (o segundo uso mais valioso). Um contador com expiração implementa "100 requisições por minuto por usuário" em duas operações atômicas:

const chave = `rate:${userId}:${minutoAtual}`;
const total = await redis.incr(chave);
if (total === 1) await redis.expire(chave, 60);
if (total > 100) throw new TooManyRequests();

É a proteção básica contra abuso de API que todo endpoint público merece.

Sessões e estado compartilhado. Lembra que o cluster proíbe estado em memória do processo? O Redis é o lugar canônico desse estado: sessões, carrinhos, presença online: rápidos, compartilhados entre workers e com expiração natural.

Rankings com Sorted Sets. O placar que seria uma query pesada com ORDER BY vira operação O(log n):

await redis.zincrby("ranking:vendas", 1, vendedorId); // ponto para o vendedor
const top10 = await redis.zrevrange("ranking:vendas", 0, 9, "WITHSCORES");

Filas e pub/sub leves. Listas (LPUSH/BRPOP) e Streams cobrem filas de trabalho simples e eventos em tempo real (o chat, a notificação). Para mensageria séria entre sistemas, com garantias fortes e DLQ, a série de mensageria deste blog cobre as ferramentas dedicadas; para o job interno do produto, o Redis costuma bastar.

O que todo mundo esquece: durabilidade é configurável

Redis é memória primeiro. A persistência existe em dois modos (redis.io/persistence): RDB (snapshots periódicos: rápido, pode perder os últimos minutos) e AOF (log de operações: mais durável, mais custo). O padrão das nuvens gerenciadas costuma ser conservador, mas a lição é de projeto:

Trate o Redis como acelerador, não como fonte da verdade. Tudo que estiver nele deve poder ser reconstruído (do banco, do evento). Se a perda de um dado do Redis causa prejuízo, esse dado morava no lugar errado.

As exceções conscientes existem (sessões perdíveis, contadores toleráveis), mas são decisões, documentadas, não acidentes.

Os tropeços de produção

• Comandos O(n) em chave gigante: KEYS * em produção é lenda urbana que ainda acontece (use SCAN); SMEMBERS num set de milhões trava o event loop do Redis, que também é single-threaded.
• Objetos gordos: serializar 2MB de JSON por chave transforma o Redis em gargalo de rede. Cacheie o que se lê, não o dump inteiro.
• Um Redis para tudo: cache volátil e fila importante na mesma instância = a política de despejo do cache um dia come a fila. Separe por função.
• Sem senha na rede interna: "é interno" não é perímetro de segurança. Auth e TLS, sempre.

O acelerador certo, no lugar certo

Decidir o que vai para o Redis (e o que continua no banco), com as invalidações e limites bem desenhados, é parte da arquitetura de dados que fazemos no serviço de Arquitetura de Software.

Sua API repete a mesma query mil vezes por minuto? Descreva o endpoint para a IA da Rabelo Digital, aqui no canto da tela, e ela desenha a camada de cache com TTL e invalidação. Sem formulário, sem espera.

---

Leia também

• DynamoDB: escala infinita com regras rígidas
• Modelagem de dados: a decisão que sobrevive aos frameworks
• PostgreSQL vs MongoDB: como escolher