Como você adicionaria uma camada de cache na frente de um endpoint pesado de leitura sem servir dados muito desatualizados?

Escolha o TTL mais curto que ainda faça diferença, depois invalide na escrita apagando ou sobrescrevendo a chave no mesmo caminho que altera a linha. Componha a chave com toda entrada que muda o resultado, incluindo tenant e uma versão de schema. Adicione um lock de execução única para um miss não causar estouro de manada no banco. Aceite desatualização explícita onde ela é inofensiva, e acompanhe a taxa de acerto para saber que aquilo está funcionando.

Antes de adicionar qualquer coisa, eu checo se a query não pode simplesmente ficar rápida, porque um cache na frente de uma query ruim esconde o problema até o cache dar miss no pior momento. Supondo que seja genuinamente pesado de leitura, eu vou de cache aside no Redis. A chave inclui o id do tenant, os parâmetros reais da query, e um prefixo de versão que eu consigo incrementar no deploy para um formato de resposta alterado nunca ser servido de entradas antigas. O TTL é a rede de segurança e não o mecanismo: eu invalido explicitamente na escrita, no mesmo caminho de código que atualiza a linha, então a janela de desatualização é de milissegundos no caso normal. O modo de falha para o qual eu me preparo é o estouro de manada, em que uma chave quente expira e duzentas requisições dão miss e batem no banco de uma vez, então eu uso um lock de execução única e deixo os perdedores esperarem o vencedor. Depois eu exporto a taxa de acerto como métrica, porque um cache que caiu de 95 por cento para 10 depois de uma refatoração passa despercebido até o banco cair.