Toda vez que um usuário abre uma página ou chama uma API, o servidor precisa trabalhar: consultar o banco de dados, montar uma resposta, aplicar regras de negócio. Quando milhares de pessoas pedem a mesma coisa ao mesmo tempo, repetir todo esse trabalho é um desperdício. É aí que entra o cache, uma das técnicas mais eficazes para acelerar um sistema back-end.
O que é cache e por que ele funciona
Cache é uma camada de armazenamento temporário que guarda o resultado de uma operação cara para reutilizá-lo nas próximas solicitações. Em vez de recalcular ou consultar a fonte original, a aplicação busca a resposta pronta em um local muito mais rápido, geralmente a memória.
Ele funciona porque muitos dados são lidos com muito mais frequência do que são alterados. A lista de categorias de uma loja, o perfil público de um usuário ou o resultado de um relatório mudam pouco, mas são pedidos o tempo todo. Guardar essas respostas reduz o tempo de resposta e alivia a carga sobre o banco de dados.
Onde o cache pode ficar
O cache não é um único componente. Ele pode existir em várias camadas de uma aplicação, e cada uma resolve um tipo de problema:
- Cache em memória na própria aplicação: guarda dados em variáveis ou estruturas do processo. É muito rápido, mas cada instância do servidor tem a sua cópia.
- Cache distribuído: ferramentas como Redis e Memcached ficam fora da aplicação e podem ser compartilhadas por vários servidores.
- Cache de banco de dados: o próprio banco mantém em memória páginas e planos de consulta usados com frequência.
- Cache HTTP e CDN: respostas são guardadas pelo navegador ou por servidores intermediários, usando cabeçalhos como Cache-Control e ETag.
Como funciona o fluxo básico
O padrão mais comum se chama cache-aside (ou “lazy loading”). Ele segue quatro passos simples:
- A aplicação recebe uma requisição e procura a resposta no cache usando uma chave.
- Se encontrar (um cache hit), devolve o valor imediatamente.
- Se não encontrar (um cache miss), consulta a fonte original, como o banco de dados.
- Antes de responder, grava o resultado no cache com um prazo de validade.
Na primeira requisição o custo é o normal. Nas seguintes, enquanto o dado estiver válido, a resposta vem direto do cache.
O grande desafio: invalidar o cache
Existe uma frase famosa entre desenvolvedores dizendo que um dos problemas mais difíceis da computação é saber quando descartar um cache. O risco é claro: se o dado original muda e o cache continua com a versão antiga, o usuário vê informação desatualizada. Algumas estratégias ajudam a controlar isso:
| Estratégia | Como funciona | Quando usar |
|---|---|---|
| Expiração por tempo (TTL) | O dado some do cache após um intervalo definido | Dados que podem ficar levemente defasados, como listas e rankings |
| Invalidação explícita | Ao alterar o dado, a aplicação remove ou atualiza a chave | Informações que precisam refletir mudanças rapidamente |
| Write-through | A escrita atualiza o banco e o cache ao mesmo tempo | Dados lidos logo após serem gravados |
| Versionamento de chave | A chave inclui uma versão, como “produto:42:v3” | Quando é mais simples criar uma chave nova do que apagar a antiga |
Escolhendo o que colocar em cache
Nem tudo merece cache. Os melhores candidatos têm três características: são consultados com frequência, são caros de produzir e toleram algum atraso na atualização. Consultas pesadas com muitos joins, resultados de cálculos, respostas de APIs externas e configurações do sistema costumam se encaixar bem.
Já dados sensíveis ou personalizados exigem cuidado. Se a resposta depende do usuário logado, a chave precisa identificar esse usuário; caso contrário, uma pessoa pode receber informações de outra. Informações que mudam a cada segundo, como saldo em tempo real, normalmente não devem ser guardadas por muito tempo.
Problemas comuns e como evitá-los
- Cache stampede: quando um item muito popular expira, muitas requisições chegam ao banco ao mesmo tempo para recriá-lo. Uma solução é permitir que apenas uma requisição reconstrua o valor enquanto as demais aguardam, ou renovar o item um pouco antes de vencer.
- Chaves mal projetadas: chaves ambíguas causam colisões e respostas erradas. Use nomes claros e inclua os parâmetros que alteram o resultado.
- TTL longo demais ou curto demais: um prazo muito longo gera dados velhos; um muito curto quase não traz ganho. Ajuste conforme a frequência real de mudança.
- Dependência excessiva: a aplicação deve continuar funcionando, mesmo que mais devagar, se o cache ficar indisponível.
Medindo o resultado
Cache sem medição é palpite. Acompanhe a taxa de acertos (quantos pedidos foram atendidos pelo cache), o tempo médio de resposta antes e depois e o uso de memória. Se a taxa de acertos for baixa, talvez as chaves estejam muito específicas ou o TTL esteja curto demais. Comece pelos pontos mais lentos do sistema, que você identifica com monitoramento, e aplique o cache onde o ganho for maior.
Conclusão
O cache é uma ferramenta poderosa, mas exige decisões conscientes: o que guardar, por quanto tempo e como invalidar. Usado com critério, ele reduz custos, melhora a experiência do usuário e ajuda a aplicação a crescer. Se você quer aprofundar esse e outros temas da programação back-end, como APIs, bancos de dados e arquitetura, vale conhecer os cursos relacionados na Cursa e avançar passo a passo, com prática.
