O que é Selective Caching? | Regras e políticas

Selective Caching é a prática de decidir quais respostas devem entrar em cache, quais devem ser ignoradas e quais regras devem ser aplicadas em cada caso. Em vez de tratar todo o tráfego da mesma forma, essa estratégia torna o comportamento do cache mais preciso, eficiente e seguro.

O que é Selective Caching?

Selective Caching é a estratégia de aplicar regras seletivas de cache com base no tipo de conteúdo, no endpoint, no método HTTP, no contexto da requisição e na sensibilidade da resposta.

Em vez de usar uma política única para tudo, ele permite decidir:

• o que pode ser armazenado em cache;
• o que deve ignorar o cache completamente;
• quais respostas exigem regras especiais;
• qual TTL faz sentido em cada cenário;
• quando aplicar bypass explícito.

Essa técnica responde a uma pergunta central:

“Quais respostas devem entrar em cache — e sob quais regras?”

Enquanto o Micro Caching define por quanto tempo uma resposta pode ser reutilizada, o Tiered Caching define em quantas camadas o cache será organizado, e o Granular Caching define como separar variantes do mesmo recurso, o Selective Caching define a política de decisão sobre o que entra ou não entra em cache.

Como funciona o Selective Caching

O Selective Caching funciona por meio de regras que avaliam cada requisição e determinam como o cache deve se comportar.

1. Elegibilidade para cache

A primeira pergunta é simples:

Esta resposta deve ser cacheada?

Nem toda resposta é candidata a cache. Operações como autenticação, autorização de pagamento, atualização de carrinho e confirmação de pedido normalmente devem ignorar o cache.

2. Classificação por contexto

Se a resposta for elegível, a estratégia considera fatores como:

• rota ou endpoint;
• método HTTP;
• presença de autenticação;
• tipo de usuário;
• sensibilidade do dado;
• frequência de atualização;
• impacto de servir uma resposta levemente desatualizada.

3. Aplicação da política

Com base nisso, o sistema pode decidir, por exemplo:

• armazenar em cache;
• não armazenar;
• aplicar TTL curto;
• aplicar TTL mais longo;
• permitir stale-while-revalidate;
• forçar bypass.

4. Construção da cache key, quando necessário

Se uma resposta for elegível e variar conforme idioma, dispositivo, segmento ou outro contexto, é preciso construir uma cache key adequada. Essa parte se conecta ao Granular Caching, que trata da segmentação por cabeçalhos, cookies e query strings.

Selective Caching vs. outras estratégias de cache

As quatro estratégias são complementares — não mutuamente exclusivas.

O papel da cache key no Selective Caching

Uma cache key é o identificador usado para localizar uma resposta armazenada em cache. No contexto de Selective Caching, ela só deve ser definida depois que a resposta já foi considerada elegível para cache.

A cache key pode incluir elementos como:

• URL;
• parâmetros de query relevantes;
• cabeçalhos que alteram a resposta;
• cookies específicos, quando isso for realmente necessário.

O desafio da otimização da cache key

Chave ampla demais

• risco de misturar respostas que deveriam ser diferentes;
• possibilidade de servir conteúdo inadequado para outro contexto.

Chave específica demais

• aumento de fragmentação;
• queda no cache hit ratio;
• menor reaproveitamento de respostas.

Chave adequada

• inclui apenas os elementos que realmente alteram o conteúdo da resposta;
• evita tanto supersegmentação quanto subsegmentação.

Importante: otimizar a cache key é parte da estratégia, mas Selective Caching não se resume a isso. O ponto central continua sendo decidir se aquela resposta deveria estar em cache.

Regras de Selective Caching

Cache por tipo de conteúdo

Diferentes tipos de conteúdo pedem políticas diferentes:

Cache por endpoint

Aplique regras específicas para endpoints diferentes:

GET api/products/*         → Cachear com TTL de 5 minutos
GET api/products/{id}      → Cachear com variação por idioma, se necessário
GET api/cart/summary       → Avaliar com muito cuidado; apenas com isolamento rigoroso e TTL curto
GET api/recommendations/*  → Cachear por segmento ou experimento, quando aplicável
POST api/cart/*            → Bypass do cache
POST api/payment/*         → Bypass do cache
POST api/orders/*          → Bypass do cache

Cache por contexto de usuário

Em alguns casos, o comportamento do cache muda conforme o contexto:

• usuários anônimos — costumam permitir cache compartilhado com mais facilidade;
• usuários autenticados — exigem análise muito mais cuidadosa;
• respostas individualizadas ou sensíveis — frequentemente não devem usar cache compartilhado.

Importante: “usuário autenticado” não significa automaticamente “não cacheável”, mas respostas autenticadas exigem critérios de elegibilidade e segmentação muito mais rigorosos.

Quando usar Selective Caching

Use Selective Caching quando:

• diferentes endpoints precisam de comportamentos diferentes de cache;
• parte da aplicação pode ser acelerada por cache e outra parte deve sempre ir à origem;
• você precisa de mais controle do que uma política genérica permite;
• existem rotas que exigem bypass explícito;
• quer tornar o cache mais eficiente sem comprometer segurança ou consistência.

Evite ou simplifique Selective Caching quando:

• todo o conteúdo é estático e segue a mesma política;
• a complexidade operacional da regra supera o ganho esperado;
• a equipe ainda não tem governança suficiente para manter políticas refinadas com segurança.

Combinando Selective Caching com outras estratégias

Selective Caching funciona melhor quando combinado com outras estratégias de cache.

Com Micro Caching:
Selective Caching decide se a resposta é elegível para cache; Micro Caching define uma janela curta de reutilização.

Com Tiered Caching:
Selective Caching define a política; Tiered Caching define a hierarquia em que essa política será aplicada.

Com Granular Caching:
Selective Caching decide quais respostas podem ser cacheadas; Granular Caching define como separar corretamente as variantes dessas respostas.

Melhores práticas para Selective Caching

1. Defina regras claras de elegibilidade

Documente explicitamente o que pode e o que não pode ser cacheado. Em caso de dúvida, comece com uma política conservadora.

2. Trate bypass como uma regra de segurança

Não dependa de comportamento implícito em operações críticas. Pagamento, autenticação, escrita e confirmações sensíveis devem ter bypass explícito.

3. Ajuste o TTL ao risco e à frequência de mudança

Nem toda resposta cacheável deve ficar o mesmo tempo em cache. Conteúdo mais dinâmico ou sensível pede TTL menor.

4. Só refine a cache key quando a resposta for elegível

Se a resposta não deveria estar em cache, não faz sentido construir uma chave sofisticada para ela.

5. Monitore efetividade por rota e política

Acompanhe métricas como cache hit ratio, latência, volume de bypass e erros por rota para validar se a estratégia está funcionando.

6. Planeje invalidação desde o início

Defina como o cache será atualizado quando o conteúdo mudar: expiração por tempo, purge por chave, tags ou eventos.

Exemplo prático: política de cache para API de e-commerce

Uma plataforma de e-commerce pode usar Selective Caching com regras como estas:

Regras de cache:

GET api/products/*         → Cachear 5 minutos
GET api/products/{id}      → Cachear 2 minutos, com variação por idioma quando necessário
GET api/cart/summary       → Somente se houver isolamento rigoroso por contexto e TTL muito curto
GET api/recommendations/*  → Cachear por segmento ou experimento, quando aplicável
POST api/cart/*            → Bypass do cache
POST api/payment/*         → Bypass do cache
POST api/orders/*          → Bypass do cache

Resultado esperado:

• navegação de catálogo mais rápida e escalável;
• redução de carga sobre a origem em endpoints de leitura;
• operações transacionais fora do cache;
• maior controle sobre onde o cache ajuda e onde ele não deve atuar.

FAQ

O que é Selective Caching?

É uma estratégia de cache que define quais respostas devem ou não devem ser cacheadas com base em regras como rota, método, contexto e sensibilidade do conteúdo.

Como o Selective Caching é diferente do cache básico?

No cache básico, uma mesma política costuma ser aplicada de forma ampla. No Selective Caching, diferentes tipos de resposta recebem políticas diferentes de elegibilidade, TTL e bypass.

Qual a diferença entre Selective Caching e Granular Caching?

Selective Caching decide quais respostas são elegíveis para cache. Granular Caching define como separar corretamente variantes diferentes dessas respostas por meio da cache key.

Quando devo usar Selective Caching?

Quando diferentes rotas, tipos de conteúdo ou contextos precisam de políticas de cache diferentes — especialmente se parte da aplicação pode ser acelerada e outra parte precisa permanecer fora do cache.

Como o Selective Caching se relaciona com bypass?

Bypass é uma das ferramentas centrais do Selective Caching. Ele garante que operações críticas ou sensíveis ignorem explicitamente o cache.

Selective Caching pode melhorar o cache hit ratio?

Pode, se ajudar a concentrar o cache nas respostas com maior potencial de reutilização e evitar regras que criem fragmentação desnecessária.

Conclusão

Selective Caching é a camada de decisão da estratégia de cache. Em vez de aplicar a mesma política para tudo, ele define onde o cache faz sentido, onde deve ser evitado e quais regras usar em cada caso.

Quando combinado com Micro Caching para TTL curto, Tiered Caching para múltiplas camadas e Granular Caching para segmentação correta, ele permite uma arquitetura de cache mais eficiente, previsível e segura.

Próximos passos

Conheça a solução de Cache da Azion e veja como ela ajuda a aplicar políticas seletivas de cache com mais controle e segurança.

Fale com um especialista Azion