Cache per request e cache compartilhado sem confundir camada

O problema

Cache vira palavra elástica rápido demais.

O time vê o mesmo dado sendo buscado mais de uma vez e conclui:

• “vamos colocar cache”

Mas quase nunca para para perguntar:

• cache onde?
• por quanto tempo?
• visível para quem?
• invalidado por quem?

Sem isso, duas coisas bem diferentes acabam misturadas:

• reaproveitar dado dentro do mesmo request
• reaproveitar dado entre requests diferentes

Modelo mental

Cache per request costuma significar:

• memoização local
• deduplicação dentro de uma execução
• evitar buscar a mesma coisa duas ou três vezes no mesmo fluxo

Cache compartilhado costuma significar:

• Redis
• memória compartilhada entre instâncias
• resultado reaproveitado por múltiplos requests e múltiplos processos

Os dois podem ser úteis.

Mas não resolvem o mesmo problema.

Quando cache per request faz mais sentido

Cache per request ajuda quando:

• o mesmo request toca o mesmo dado mais de uma vez
• múltiplas partes do fluxo pedem a mesma entidade
• você quer reduzir trabalho repetido sem criar estado externo

Exemplo simples:

um request carrega o usuário atual no middleware, depois o use case pede o mesmo usuário, depois uma checagem de permissão consulta de novo.

Isso não pede Redis.

Pede só uma camada local de reaproveitamento durante a execução.

O ganho aqui costuma ser:

• simplicidade
• zero invalidação distribuída
• menos repetição interna

Quando cache compartilhado entra

Cache compartilhado começa a fazer sentido quando:

• múltiplos requests repetem leitura cara
• o custo da origem é alto demais
• o dado tolera staleness controlada
• várias instâncias precisam reaproveitar o mesmo valor

Exemplos:

• configuração lida o tempo todo
• catálogo pouco mutável
• projeção cara de dashboard
• resposta agregada que não precisa ser perfeita em tempo real

Aqui já existe outro tipo de pergunta:

• quanto tempo esse dado pode envelhecer?
• o que dispara invalidação?
• o que acontece se o cache cair?

O erro comum

O erro comum é usar cache compartilhado para resolver problema local.

Exemplo:

• o mesmo request faz três consultas iguais
• em vez de corrigir o fluxo ou usar cache por request, o time põe Redis no meio

Isso cria:

• serialização
• rede
• chave
• invalidação
• observabilidade extra

para resolver uma repetição que morava dentro do mesmo processo.

O erro inverso também existe.

Tem sistema tentando reaproveitar dado global com variável local de processo, como se isso bastasse em ambiente com múltiplas instâncias.

Exemplo simples

Imagine uma API de listagem de pedidos.

No mesmo request:

• você precisa traduzir customerId para nome em vários pontos

Talvez um cache per request já baste para não buscar o mesmo cliente cinco vezes.

Agora imagine:

• a página inicial consulta sempre os mesmos indicadores de operação a cada poucos segundos

Aí talvez faça sentido um cache compartilhado com TTL curto.

São problemas diferentes.

Tratar ambos como “cache” sem contexto só esconde a decisão real.

Como um senior pensa

Quem decide melhor costuma perguntar:

• o reaproveitamento precisa viver só durante este request?
• o valor pode ser compartilhado entre requests?
• o dado tolera envelhecer?
• quem inválida e com qual semântica?
• estou melhorando arquitetura ou só escondendo consulta ruim?

Essas perguntas evitam o uso automático de Redis para tudo.

Ângulo de entrevista

Esse tema aparece em performance, backend e system design.

O entrevistador normalmente quer ver se você distingue:

• deduplicação local
• cache distribuído
• consistência
• custo operacional

Resposta forte costuma soar assim:

“Se o problema for repetição dentro do mesmo request, eu começaria com cache local por execução. Cache compartilhado eu deixaria para leitura repetida entre requests, quando a origem é cara e a semântica de invalidação está clara.”

Takeaway direto

Cache bom não é o que aparece mais cedo.

É o que resolve a repetição certa na camada certa.