1 Por que usar Redis como cache

O Redis é um armazenamento em memória de alto desempenho, com suporte a estruturas de dados ricas (strings, hashes, listas, conjuntos, sorted sets, etc.). Quando utilizado como cache, ele reduz a latência de leitura e alivia o banco de dados primário, melhorando a escalabilidade de aplicações com picos de tráfego.

• Latência tipicamente sub-miléssima em operações simples de leitura.
• Suporte a TTL (_time to live_), permitindo expirar chaves automaticamente.
• Políticas de expiração e evicção para gerenciar memória de forma previsível.
• Possibilidade de padrões de cache simples e eficientes, como Cache-Aside, Read-Through, e Write-Through (quando apropriado).

2 Padrão Cache-Aside (Lazy Load)

O padrão Cache-Aside é o mais comum para aplicações que acessam dados com perfil de leitura variável. A ideia é consultar o Redis primeiro e, em caso de miss, buscar no armazenamento principal (por exemplo, banco de dados), atualizar o cache e retornar o resultado.

• Vantagens: simplicidade, controle explícito de invalidação e custo de cache baixo para dados com baixa taxa de atualização.
• Desvantagens: latência de miss pode impactar usuários finais; requer lógica adicional na aplicação.

1. Gerar uma chave de cache com namespace claro, por exemplo: user:123:profile
2. Checar Redis: se houver, retornar já deserializado
3. Se faltar, buscar do primary store, serializar e gravar no cache com TTL adequado
4. Definir TTL com base na natureza dos dados (ex.: sessões, leituras que mudam raramente)

// Exemplo simplificado em Node.js (usando ioredis)
const Redis = require('ioredis');
const redis = new Redis();

async function getUserProfile(userId) {
  const key = `user:${userId}:profile`;
  const cached = await redis.get(key);
  if (cached) {
    return JSON.parse(cached);
  }
  // Simulação de fetch no DB
  const profile = await db.getUserProfile(userId);
  // Armazena no cache com TTL de 3600 segundos
  await redis.set(key, JSON.stringify(profile), 'EX', 3600);
  return profile;
}

3 TTL, Eviction e políticas de cache

Gerenciar memória é essencial para caches em memória. TTL (tempo de vida) evita o acúmulo de dados desatualizados, enquanto políticas de evicção determinam quais chaves são removidas quando a memória chega ao limite.

• TTL adequado: defina expirações por tipo de dado (ex.: 5 min para dados de sessão, 1–24 h para dados menos sensíveis).
• Políticas de evicção comuns no Redis: allkeys-lru, allkeys-random, volatile-lru, volatile-ttl, noeviction (quando memória atinge teto).
• Prefira armazenar objetos menores e serialização leve. Evite armazenar grandes blobs sem necessidade.
• Considere usar estruturas nativas do Redis (hashes, sets) para reduzir overhead por chave.

4 Boas práticas: configuração, monitoramento e cenários

• Separar cache de produção do cache de desenvolvimento/testes para evitar interferências.
• Usar nomes de chave com namespace e evitar hot keys (chaves muito demandadas que causam gargalo).
• Adoção de replicas para leituras escaláveis e failover; considere AOF para durabilidade, com políticas de flush apropriadas.
• Configurar timeouts de conexão e pool adequado para o tamanho da aplicação.
• Monitorar métricas como hit rate, latency, uso de memória, e eficiência de TTL via INFO e dashboards (ex.: Redis-Stat, Prometheus exporters).
• Rotina de invalidação/coerência: introduzir invalidação explícita no write quando necessário, principalmente em dados sensíveis a coerência.

Código Exemplo de configuração básica de TTL e políticas

// Exemplo de configuração de Redis (redis.conf)
# TTL e políticas de evicção
maxmemory 256mb
maxmemory-policy allkeys-lru
# Persistência opcional
appendonly yes