Melhores Práticas de Cache

Defina a invalidação antes de armazenar em cache caminhos de alta demanda. O Redis é rápido; um design de cache incorreto é lento para depurar.

Como Usar Esta Lista

• Exija uma nota de design de cache em PRs que adicionam novas famílias de chaves
• Execute testes de carga com o Redis desabilitado para verificar o caminho de degradação
• Combine com Fundamentos de Cache para padrões
• Revise os TTLs após alterações de esquema ou formato de API

A - Design de Chaves

• Chaves com namespace: env:service:version:entity:id.
• Proprietário da invalidação nomeado em comentário de código ou ADR por família de chaves.
• TTL em cada chave a menos que configuração explícita eterna com invalidação por stream de alteração.
• Cardinalidade de chave limitada - sem strings geradas pelo usuário sem limites nas chaves.
• Aumento do prefixo de versão quando o formato serializado muda.

B - Consistência

• Cache-aside com o banco de dados como fonte da verdade para a maioria das leituras.
• Excluir ou atualizar o cache na escrita no mesmo caso de uso da mutação do banco de dados.
• Proteção contra estampido nas chaves mais acessadas (lock, jitter, atualização antecipada).
• TTL curto para cache negativo (resultados de miss) para proteger o banco de dados.
• Não armazenar em cache saldos financeiros fortemente consistentes sem aprovação explícita do produto.

C - Operações

• Cliente ioredis singleton por processo com manipulador de erros.
• Alertas de memória na instância Redis (maxmemory, evictions).
• Métricas de acerto/erro por endpoint ou prefixo de chave em staging antes de produção.
• Separar banco de dados lógico Redis ou instância para BullMQ vs cache voltado para o usuário quando a carga for alta.
• TLS e AUTH habilitados no Redis gerenciado em produção.

D - Segurança

• Sem segredos em valores de cache a menos que criptografados em nível de aplicativo.
• Cookies de sessão contêm apenas IDs - veja Armazenamento de Sessão.
• Isolamento multi-inquilino em cada prefixo de chave.
• Redis não exposto à internet pública - apenas VPC/link privado.
• Usuários ACL com privilégio mínimo no Redis 6+.

E - Integração com Aplicativo

• Degradação graciosa quando o Redis expirar - registrar e retornar à origem.
• Tamanho do payload JSON revisado - cache DTOs, não grafos de objetos completos.
• Pipeline multi-get para leituras em lote em vez de N gets sequenciais.
• redis.quit() no desligamento junto com o fechamento do pool HTTP e do banco de dados.
• Locks distribuídos mantidos por < poucos segundos - veja Locks Distribuídos.

F - Quando Não Armazenar em Cache

• Pular cache quando a taxa de acertos < 30% após o período de medição.
• Pular dados mutáveis por usuário com poucas leituras repetidas dentro da janela de TTL.
• Preferir CDN para ativos públicos estáticos antes do Redis.
• Preferir índice de banco de dados antes do Redis se a consulta for lenta devido à falta de índice.
• Enfileirar recomputação pesada em vez de blobs em cache gigantes.

FAQs

Relacionados

• Fundamentos de Cache - exemplos de cache-aside
• ioredis - padrões de cliente
• Armazenamento de Sessão - sessões de cookie
• Fundamentos de Desempenho - latência
• Fundamentos de Resiliência - modos de degradação

Versões da Pilha: Esta página foi escrita para Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 e NestJS 11.