Cache com Redis: respostas rápidas sem servir dados velhos

Algumas consultas são caras e mudam pouco: catálogo de produtos, configurações, rankings, relatórios agregados. Executá-las a cada requisição desperdiça banco e tempo de resposta. Um cache em memória, como o Redis, resolve.

O padrão mais comum

1. 1.A requisição chega.
2. 2.O sistema procura o resultado no cache.
3. 3.Se encontra, devolve na hora.
4. 4.Se não, consulta o banco, guarda no cache com prazo de validade e devolve.

O problema difícil: invalidar

"Há duas coisas difíceis em computação: invalidar cache e dar nomes." Servir preço antigo ou estoque errado é pior do que ser lento.

• Prazo de validade curto para dados que mudam com frequência.
• Invalidação ativa: quando o produto é alterado, o cache dele é removido.
• Chaves bem pensadas: produto:123, catalogo:categoria:7:pagina:2.

O que não colocar em cache

Dados pessoais sensíveis sem cuidado, saldo, informações que mudam a cada segundo e resultados que dependem de permissões, a menos que a chave inclua o usuário.

Cuidado com o "efeito manada"

Quando um item muito acessado expira, centenas de requisições vão ao banco ao mesmo tempo. Técnicas de bloqueio ou renovação antecipada evitam o pico.

Redis faz mais que cache

Contadores de rate limit distribuído (Rate limit distribuído com Redis: quando um servidor não basta), filas de tarefas (Filas e jobs em background: tirando tarefas pesadas da requisição) e sessões.

E antes de cachear, vale verificar se a consulta não está lenta por falta de índice (Índices no banco de dados: a otimização mais barata que você ainda não fez).

A We Codex otimiza APIs em sistemas web e Performance WPO. Fale com a gente.