O cache pode reduzir os tempos de resposta e a carga sobre bancos de dados ou serviços externos, mas não corrige, por si só, uma consulta ineficiente nem uma arquitetura com limites mal definidos. Uma estratégia de cache em PHP deve especificar o que é armazenado, quem pode recebê-lo, por quanto tempo é válido e o que acontece se o mecanismo de armazenamento falhar.
O critério de sucesso não é apenas aumentar a taxa de acertos. A aplicação deve manter suas regras de negócio quando o cache estiver vazio, desatualizado ou indisponível. Para isso, convém começar medindo o problema e tratar o cache como uma otimização com comportamento verificável, não como fonte primária da verdade.
Meça antes de decidir o que armazenar
Identifique primeiro as rotas lentas e suas causas. Registre os tempos de resposta por endpoint, a latência das consultas, as chamadas a serviços externos, o uso de CPU e o volume de requisições. Separe as médias dos percentis mais altos: uma média aceitável pode ocultar respostas muito lentas para parte dos usuários.
Procure operações repetidas cujo resultado mude com menos frequência do que a demanda: catálogos, configurações públicas, conteúdo publicado ou agregações custosas. Verifique também se a lentidão é causada por consultas sem índices, excesso de solicitações, serialização ou trabalho repetido dentro da mesma requisição. Melhorar a consulta pode ser preferível a armazenar um resultado difícil de invalidar.
Defina uma referência antes da mudança: desempenho, carga e qualidade dos dados observada. Depois, compare o mesmo tráfego ou um teste reproduzível. Se não for possível atribuir a melhoria ao cache, será difícil avaliar seu custo operacional e seus efeitos colaterais.
Escolha entre cache de aplicação, HTTP e consultas
O cache de aplicação armazena valores que o código PHP pode reutilizar, como resultados de uma consulta ou uma resposta calculada. Pode residir em memória compartilhada, em um serviço dedicado ou em outro backend compatível com a aplicação. É adequado quando várias requisições precisam do mesmo resultado e é possível definir com precisão seu escopo e período de validade.
O cache HTTP usa diretivas como Cache-Control, ETag e validadores para que navegadores ou intermediários reutilizem respostas. É útil para recursos públicos ou respostas cuja política de privacidade permite o armazenamento. Respostas personalizadas exigem cuidado especial: uma política pública pode expor dados, enquanto uma política privada ou que impeça o armazenamento pode reduzir essa possibilidade, dependendo do fluxo e dos intermediários envolvidos.
O cache de consultas pode ser uma funcionalidade do banco de dados, do driver ou de uma camada que conserva resultados. Não deve ser confundido com a otimização do acesso aos dados: o cache não substitui índices, planos de consulta adequados nem transações. Antes de ativá-lo, entenda quem invalida as entradas e se as leituras precisam refletir imediatamente as gravações.
Escolha a camada mais próxima do problema, não todas ao mesmo tempo. Empilhar caches sem um modelo explícito pode fazer com que diferentes camadas mantenham versões distintas dos mesmos dados e dificultar o diagnóstico.
Projete chaves, escopo e expiração
Uma chave deve identificar todos os fatores que alteram o resultado. Por exemplo, uma resposta de catálogo pode depender do idioma, da moeda, da região e da versão dos dados. Inclua esses elementos de forma estável e legível para facilitar o diagnóstico; evite armazenar informações confidenciais na chave.
Se o resultado depender do usuário, do papel, das permissões ou da organização, o isolamento deve refletir isso. Uma chave que inclua apenas o nome da rota pode fazer com que uma resposta personalizada chegue a outra pessoa. Verifique também como as entradas são compartilhadas entre processos e servidores. Se não for possível enumerar de forma confiável todas as dimensões que afetam o resultado, não armazene essa resposta de forma compartilhada.
A expiração deve obedecer a uma regra de negócio, não a um valor arbitrário. Uma configuração que muda poucas vezes pode tolerar uma janela mais longa do que o saldo de uma conta ou o estado de uma reserva. Defina o tempo máximo aceitável de desatualização e considere variações aleatórias na expiração quando muitas entradas semelhantes puderem vencer ao mesmo tempo.
A expiração por tempo não substitui a invalidação diante de mudanças importantes. É um limite máximo para que uma entrada não permaneça indefinidamente, não uma garantia de atualização imediata.
Atualize e invalide quando a origem mudar
Escolha um mecanismo adequado à necessidade de coerência. A invalidação explícita pode ser executada após uma gravação; é direta, mas pode falhar se o processo for interrompido entre salvar os dados e limpar o cache. Uma alternativa é usar versões nas chaves: quando a origem muda, a versão é incrementada e as entradas anteriores deixam de ser consultadas. Isso exige gerenciar essa versão corretamente.
Em sistemas orientados a eventos, uma mudança confirmada pode publicar uma notificação para invalidar ou recalcular dados derivados. Se a entrega de eventos não for confiável, considere novas tentativas, idempotência e um mecanismo de reconciliação. Não presuma que atualizar o banco de dados e o serviço de cache constitua uma operação atômica.
Para dados que toleram um breve período de desatualização, pode ser adequado servir uma entrada vencida enquanto ela é atualizada em segundo plano. Essa técnica não serve para todos os tipos de informação: determine quais dados são elegíveis, por quanto tempo a desatualização pode se prolongar e o que acontece se a atualização falhar. A decisão deve se basear no impacto de exibir um valor anterior.
Defina um comportamento seguro diante de falhas
Teste três estados distintos: ausência de entrada, entrada vencida e backend indisponível. Em cada um, decida se a aplicação recalcula a partir da origem, responde com um erro controlado ou, quando for seguro, entrega um valor anterior. Um cache vazio deve ser um estado normal de inicialização e não provocar resultados incorretos.
Proteja a origem contra uma falha do backend. Se cada requisição disparar uma consulta custosa quando a mesma chave expirar, poderá ocorrer uma avalanche de carga. Entre as medidas possíveis estão limitar a concorrência dos recálculos, reutilizar temporariamente valores seguros ou aplicar limites e tempos de espera. A solução depende de os dados poderem ser servidos desatualizados e da capacidade da origem.
Registre erros, latências e falhas de leitura ou gravação sem incluir valores privados. O cache costuma ser uma dependência de desempenho, não uma autoridade de dados: se sua indisponibilidade tiver de interromper uma operação crítica, essa decisão precisa ser explicitamente justificada.
Valide a coerência e o desempenho com testes reproduzíveis
Compare cenários com o cache desativado, frio e aquecido. Inclua a primeira requisição após uma gravação, mudanças de idioma ou permissões, expiração simultânea e falha do backend. Verifique tanto o conteúdo quanto o isolamento: dois usuários com permissões diferentes não devem receber respostas cruzadas.
Use testes automatizados para regras importantes de chaves e invalidação e testes de integração para verificar o comportamento com o backend real ou uma alternativa representativa. Em testes de carga, observe acertos e falhas, latência do cache, operações de recálculo, carga da origem e erros. Uma taxa de acertos alta não demonstra que as respostas estejam corretas.
Ao implantar uma mudança, compare métricas e erros com uma referência. Mantenha uma forma de desativar a otimização ou voltar a um comportamento seguro se surgirem dados desatualizados, aumento do uso de memória ou pressão inesperada sobre o banco de dados.
Lista de verificação para operar o cache
- Problema medido: as rotas e operações que justificam o cache são conhecidas.
- Dados e origem definidos: o cache não é tratado como registro primário.
- Chave completa: inclui as dimensões funcionais e de permissões relevantes.
- Expiração justificada: corresponde à tolerância do negócio à desatualização.
- Invalidação planejada: especifica qual evento atualiza ou substitui cada entrada.
- Falhas cobertas: o comportamento para cache vazio, vencido e indisponível está definido.
- Medição operacional: latência, erros, acertos e carga sobre a origem são monitorados.
- Testes de isolamento: usuários, papéis, idiomas e outros contextos pertinentes são validados.
Uma estratégia de cache sólida reduz o trabalho repetido sem alterar inadvertidamente o significado dos dados. Se cada entrada tiver um escopo claro, uma política de validade e um plano de falha verificável, a equipe poderá avaliar seus benefícios e remover ou ajustar a otimização quando ela deixar de ser adequada.
