Uma cache guarda temporariamente uma cópia de dados ou resultados para evitar repetir um trabalho dispendioso. Pode acelerar uma aplicação e reduzir a pressão sobre uma base de dados ou um serviço externo. Mas não é uma melhoria automática: acrescenta regras de atualização, riscos de incoerência e uma nova dependência operacional.
A pergunta útil não é «podemos adicionar uma cache?», mas sim que operação concreta queremos melhorar e que custo aceitamos em troca? Este guia ajuda a responder, desde o diagnóstico inicial até à validação e à remoção.
Que problema resolve uma cache e que problemas não corrige
Uma cache é adequada quando a mesma informação ou o mesmo resultado calculado são pedidos repetidamente e voltar a produzi-los tem um custo relevante. Esse custo pode ser o tempo de consulta, o consumo de recursos, uma chamada a outro serviço ou a latência sentida pela pessoa utilizadora.
Por outro lado, armazenar respostas não corrige, por si só, uma consulta mal concebida, um algoritmo ineficiente, uma interface que faz pedidos em excesso nem uma dependência lenta em todas as situações. Pode ocultar esses defeitos durante algum tempo, ao mesmo tempo que dificulta o diagnóstico do sistema. Se cada pedido for diferente ou os dados mudarem continuamente, poderá haver poucos acertos e a camada adicional poderá não compensar.
Antes de conceber uma cache, formule um objetivo verificável: por exemplo, reduzir a latência de uma leitura frequente ou diminuir as consultas repetidas a uma dependência. Esclareça também que métrica deve melhorar, em que percurso e para que utilizadores.
Sinais para considerar uma cache
A hipótese ganha força se as medições revelarem uma combinação dos seguintes sinais:
- Leituras repetidas: pedidos diferentes precisam dos mesmos dados ou do mesmo resultado dentro de um determinado intervalo.
- Custo elevado na origem: consultar a base de dados, calcular uma resposta ou chamar um serviço demora o suficiente para afetar o percurso.
- Pressão sobre uma dependência: o volume de pedidos ameaça a capacidade, os limites ou a estabilidade do sistema.
- Reutilização previsível: é possível identificar uma chave estável que distingue os resultados, como o idioma, as permissões ou os filtros relevantes.
Uma latência elevada, por si só, não basta. Verifique onde se consome o tempo e se a maioria dos pedidos poderia reutilizar um resultado. Meça os tempos de resposta por operação, o volume, os erros e a frequência de repetição. Se a aplicação servir conteúdos a utilizadores diferentes, confirme que a chave também distingue corretamente as respetivas permissões e o contexto.
Quando otimizar antes de acrescentar outra camada
Comece pela origem quando o problema estiver aí. Reveja as consultas lentas, os índices adequados, os dados desnecessários, as chamadas redundantes e o trabalho que poderia ser executado uma só vez. Para uma operação dispendiosa, compare o custo de a corrigir com o de manter uma cache. A otimização tende a ser preferível se melhorar todos os casos, incluindo aqueles em que não é possível reutilizar uma resposta.
Também convém investigar se a lentidão surge apenas com concorrência, num serviço externo ou numa parte específica do percurso. Uma cache pode ajudar em algumas destas situações, mas não necessariamente em todas. Se o resultado depender de informação que muda a cada pedido, uma cópia armazenada poderá ser inútil ou enganadora.
Teste primeiro a intervenção mais pequena que possa confirmar a causa. Se ajustar uma consulta resolver o problema, não há motivo para assumir o custo de uma camada adicional. Se persistir uma repetição mensurável e os dados tolerarem alguma desatualização, faz sentido avaliar uma cache.
Que dados armazenar e onde
Dê prioridade a dados consultados com frequência, dispendiosos de obter e que mudam pouco, ou cuja atualização mais lenta tenha sido expressamente aceite. Em contrapartida, evite armazenar sem uma justificação clara dados pessoais ou sensíveis, informação que exija coerência imediata e resultados pouco reutilizados. Defina o que contém cada entrada, quanto espaço pode ocupar, como é identificada e quem lhe pode aceder.
O âmbito depende do fluxo:
- Cliente: pode evitar pedidos repetidos no navegador e melhorar a rapidez percebida. O servidor continua a ser responsável por autorizar o acesso; não confie nos dados do cliente como fonte de permissões ou de verdade.
- Servidor: é útil quando vários utilizadores ou pedidos podem reutilizar o mesmo resultado. A chave deve incluir todas as variáveis que alteram a resposta, incluindo identidade, permissões e configuração, quando aplicável.
- Infraestrutura: uma cache de respostas ou conteúdos pode servir pedidos repetidos antes de chegarem à aplicação. É importante configurar o âmbito e as regras de armazenamento para não expor respostas privadas.
Não escolha uma localização por hábito. Acompanhe o percurso dos dados e decida onde a reutilização pode ocorrer sem misturar contextos nem desrespeitar requisitos de privacidade.
Expiração, invalidação e atualidade
A expiração define durante quanto tempo uma entrada pode ser reutilizada antes de ser considerada caducada. É simples, mas a informação pode ficar desatualizada durante esse intervalo. A invalidação explícita elimina ou atualiza entradas quando os dados de origem mudam, embora exija uma ligação fiável entre as escritas e as chaves afetadas. Nenhuma estratégia é universal.
Para cada dado, estabeleça uma tolerância máxima à desatualização. Se uma ficha informativa puder apresentar alguns minutos de atraso, uma duração limitada poderá ser aceitável. Para inventário, saldos, permissões ou estados que condicionem uma ação, determine se é necessário consultar a origem antes de confirmar. Não presuma que uma cache garante coerência entre réplicas ou processos.
Documente que evento invalida a entrada, o que acontece se a atualização falhar e como evitar que muitos pedidos simultâneos voltem a calcular o mesmo resultado. Se a atividade exigir atualização imediata, poderá ser mais adequado não armazenar esse dado no fluxo crítico ou usar a cache apenas como apoio, sem a tornar a fonte de autoridade.
Falhas e degradação controlada
Uma cache pode não responder, perder entradas ou devolver dados caducados. Decida antecipadamente o que a aplicação fará em cada caso: consultar a origem, devolver uma resposta limitada ou apresentar um erro. A alternativa depende da importância dos dados e da capacidade da dependência. Se todos os pedidos passarem ao mesmo tempo para a origem após uma falha, a recuperação poderá gerar sobrecarga adicional.
Defina limites de memória e o comportamento perante entradas inválidas. Para operações sensíveis, verifique a autorização no momento adequado e evite que uma chave partilhada exponha dados de outra conta. Trate as falhas da cache como uma condição que deve ser observada e testada, e não como uma exceção improvável.
Como validar se a cache compensa
Estabeleça uma linha de base antes da alteração e compare o mesmo percurso depois. Observe a latência, os erros, a carga sobre a origem e o comportamento com uma procura representativa. Acrescente métricas de acertos e falhas da cache, mas não confunda uma taxa elevada de acertos com uma melhoria para o utilizador: o que importa é que o resultado final melhore sem prejudicar a atualidade ou a fiabilidade.
Reveja também os casos de expiração, invalidação e falha. Se o benefício só surgir em condições pouco frequentes, ou se o custo operacional ultrapassar o impacto medido, reconsidere a decisão. Mantenha a possibilidade de remover a camada e comparar resultados, sobretudo se os padrões de utilização mudarem.
Lista de verificação antes da implementação
- Existe uma operação concreta e uma linha de base mensurável?
- As leituras repetem-se e é dispendioso obter ou calcular o resultado?
- Foram excluídas melhorias mais simples na origem?
- A chave está definida, incluindo as permissões e o contexto?
- Foi acordado que nível de desatualização dos dados é aceitável?
- Existe um plano de expiração, invalidação e resposta a falhas?
- Serão medidos os resultados para os utilizadores, a carga e os erros, além dos acertos?
Use uma cache quando as medições confirmarem uma oportunidade de reutilização e for possível gerir os riscos. Se não conseguir explicar o que é armazenado, durante quanto tempo e o que acontece quando fica desatualizado, ainda falta tomar uma decisão de conceção essencial.