System Design/03 - Qualidade/Performance Antipatterns2 min
No Caching
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Recalcular ou rebuscar repetidamente o mesmo resultado imutável ou raramente alterado.
O sinal é sempre o mesmo: alta razão leitura:escrita sobre dados que mudam pouco. Um catálogo lido 10 mil vezes por minuto e alterado uma vez por dia executa a mesma consulta milhares de vezes para produzir a mesma resposta.
O que quase sempre vale cachear
- Configuração e feature flags
- Dados de referência (países, categorias, tabelas fixas)
- Perfil de usuário, permissões
- Resultado de consulta cara e estável
- Resposta de API externa lenta ou com rate limit
- Conteúdo estático — na borda, não na aplicação (CDN Caching)
Camadas e estratégias em Caching.
Trade-offs
O antipadrão oposto é cachear onde não se deve, e ele é igualmente comum:
| Não cacheie | Motivo |
|---|---|
| Dado que muda a cada leitura | Hit rate zero; só adiciona um salto |
| Dado personalizado por usuário na borda | Fragmenta a cache key |
| Resultado de escrita | Torna a inconsistência observável |
| Dado sensível sem controle | Risco de vazamento entre sessões |
A métrica que decide é o hit rate. Abaixo de ~80%, o cache está cobrando complexidade de invalidação, mais um componente para operar e um salto de rede — e entregando pouco.
E o custo real de cachear não é a memória: é a invalidação. Toda entrada de cache é uma cópia que pode ficar errada, e todo caminho de escrita passa a ter a obrigação de lembrar de invalidá-la. Esquecer um deles produz o bug mais difícil de reproduzir: "às vezes aparece o dado antigo".
Por isso TTL curto costuma ser preferível a invalidação explícita: aceita-se uma janela de desatualização em troca de nunca depender de alguém lembrar.
Exemplo prático
Um endpoint de configuração chamado a cada requisição da aplicação:
sem cache: 5.000 consultas/s ao banco para ler 12 linhas que mudam 1x por dia
com cache: TTL de 60 s → ~1 consulta por minuto
De 5.000 para 0,017 consultas por segundo — cinco ordens de grandeza, com uma linha de código.
O custo aceito: uma mudança de configuração leva até 60 segundos para propagar. Se isso for inaceitável para uma flag específica, o caminho é invalidação explícita naquela chave — não abandonar o cache das outras onze.
Relacionado
Parte de Performance Antipatterns · roadmap.sh/system-design