O cache HTTP parece simples; acertar a chave de cache e o tratamento de exceções em produção é difícil.
O cache HTTP é simples em teoria: quando os valores de Cache-Control, ETag e TTL estão corretos, clientes e intermediários reutilizam a mesma resposta. Em produção, as aplicações rotineiramente enviam esses headers ausentes, incorretos ou excessivamente restritivos. O resultado é que conteúdo cacheável continua atingindo o backend desnecessariamente.
Mesmo para ativos estáticos, pequenas diferenças de URL corroem a eficiência do cache. A mesma imagem de produto ou página de catálogo pode se comportar como um objeto diferente por causa de parâmetros de rastreamento. Host, query string, headers do cliente ou um header Cache-Control mal configurado reduzem desnecessariamente a taxa de acertos do cache.
Para conteúdo dinâmico o problema é maior. O mesmo path pode retornar respostas diferentes para mobile e desktop; preços podem variar por país; o mesmo endpoint pode produzir dados diferentes por tenant. Se a chave de cache não carrega esse contexto, o conteúdo errado é retornado. Adicione muitos headers à chave de cache e o cache mal funciona.
Soluções externas de cache ou CDN são úteis na borda da internet, mas nem sempre são adequadas para tráfego on-premises, de API privada ou de nuvem soberana. Fazer cache na camada ADC tipicamente requer arquivos de configuração, uma linguagem de regras personalizada ou um produto separado.
O Cache de Resposta do TR7 reúne perfis de cache, regras condicionais, chaves de cache dinâmicas e opções padrão de substituição em um único modelo de gerenciamento de vService.
Nossa abordagem
O TR7 gerencia o comportamento de cache por meio de quatro camadas: perfis, condições, chaves dinâmicas e substituições controladas.
Perfis de cache nomeados fornecem cotas por serviço
Um perfil de cache reúne nome, tamanho, TTL, ETag e configurações de header de debug em um único lugar. O mesmo perfil pode ser compartilhado entre múltiplos vServices enquanto cada serviço é governado por seus próprios limites de cache.
Regras de cache condicionais tomam decisões por endpoint
Cada regra de cache se vincula a path, método, header, cookie ou outras variáveis por meio do mecanismo de condição FX. Um catálogo público no mesmo backend pode ser cacheado enquanto o carrinho do usuário é excluído — sem alterar nenhum código de aplicação.
Chaves de cache dinâmicas previnem respostas com conteúdo errado
País, tipo de dispositivo, ID de tenant, segmento de usuário ou um header personalizado podem ser adicionados à chave de cache. A mesma URL se divide em slots de cache separados por contexto, preservando a velocidade do cache enquanto fortalece a correção do conteúdo.
Opções padrão de substituição melhoram a eficiência do cache
Verificações de Host, query string, header de requisição e header de resposta podem cada uma ser deliberadamente ignoradas. Backends mal configurados ou parâmetros de rastreamento não suprimem mais as taxas de acertos. Os operadores decidem explicitamente qual padrão substituir e quando.
Capacidades
O Cache de Resposta torna cada comportamento — desde o perfil de cache até a chave dinâmica — configurável no nível de vService.
Perfis de cache nomeados centralizam a configuração de tamanho e TTL
Cada perfil é definido com um nome, tamanho máximo e timeout. O limite de tamanho mantém o uso de cache por serviço sob controle. O timeout é configurável em segundos, minutos ou horas. Aplicar o mesmo perfil a múltiplos vServices reduz a repetição operacional.
Cache hit e miss são visíveis via um header de resposta
O TR7 pode adicionar um header de debug às respostas, permitindo que um desenvolvedor ou operador veja no painel Network do navegador se uma resposta veio do cache ou do backend. Nenhuma ferramenta de log adicional é necessária para verificação rápida — acelera o comissionamento e a sintonia.
A lista de regras de cache condicionais fornece controle por endpoint
Múltiplas regras podem ser definidas dentro de um único perfil de cache. Cada regra é acionada por condições de path, método, header, cookie ou FX. `/assets/*` pode ser cacheado por muito tempo enquanto `/api/cart` é excluído. Diferentes comportamentos de cache dentro de um vService são gerenciados a partir de um único painel.
O suporte a ETag elimina transferências de dados desnecessárias
ETag pode ser habilitado por regra. Quando um cliente solicita o mesmo objeto novamente e o conteúdo não mudou, ele recebe uma resposta de validação em vez do corpo completo. Isso reduz o consumo de largura de banda e é especialmente eficaz para ativos estáticos e respostas de API que mudam com pouca frequência.
Chaves de cache dinâmicas criam slots separados por contexto
Quando o cache dinâmico está ativo, variáveis personalizadas podem ser adicionadas à chave de cache. País, tipo de dispositivo, ID de tenant, grupo de teste A/B ou um valor extraído de um JWT podem todos tornar-se parte da chave. A mesma URL se separa de forma limpa entre contextos. Isso torna o cache prático para cenários modernos de API e SaaS.
Ignorar Host consolida conteúdo multi-domínio em um único slot de cache
Quando o mesmo backend serve conteúdo idêntico sob múltiplos domínios, o Host pode ser removido da chave de cache. Domínios como `a.example` e `b.example` podem então compartilhar o mesmo objeto cacheado, reduzindo a duplicação de cache. Essa opção deve ser usada apenas quando o conteúdo é genuinamente compartilhado.
Ignorar query string impede que parâmetros de rastreamento quebrem o cache
`utm_source`, códigos de campanha e parâmetros de analytics podem fazer o mesmo conteúdo aparecer como objetos diferentes. Com o ignore de query string ativo, esses parâmetros são excluídos da chave de cache. A mesma página sob múltiplas variantes de parâmetros de rastreamento não atinge mais o backend repetidamente. As taxas de acertos para conteúdo público melhoram visivelmente.
Ignorar verificação de requisição limita o cache busting do lado do cliente
Alguns clientes ou bots adicionam headers que tentam ignorar o caching em toda requisição. O ignore de verificação de requisição permite que esse comportamento seja deliberadamente desconsiderado. Conteúdo estático e respostas de API públicas são protegidos de carga desnecessária no backend. Essa configuração deve ser aplicada com cuidado em endpoints sensíveis à segurança.
Ignorar verificação de resposta pode substituir headers de backend mal configurados
Um backend pode enviar erroneamente `no-store` ou headers de cache excessivamente restritivos. O ignore de verificação de resposta permite que os operadores ignorem deliberadamente esses headers. Os benefícios do cache são obtidos sem alterar o código da aplicação. Essa opção deve ser usada apenas para respostas determinísticas e seguras.
O cache de todos os métodos suporta cenários de POST do GraphQL
O comportamento padrão de cache HTTP foca em respostas GET e HEAD. O TR7 permite que os operadores incluam respostas POST no escopo de cache também. Isso é especialmente útil quando queries GraphQL chegam via POST. Hash de corpo ou variáveis FX relevantes podem ser adicionados à chave de cache para garantir separação segura.
O cache baseado em memória é gerenciado por meio de soft reload
O cache é mantido em memória de runtime. Mudanças de configuração são aplicadas via um modelo de soft reload; nenhum endpoint de invalidação em runtime é necessário. Atualizar um perfil de cache ou regra atualiza o comportamento de cache relevante. Quando o dispositivo reinicia, o cache começa a aquecer novamente do zero.
Objetos menos recentemente usados são expulsos automaticamente
Quando o limite de tamanho do cache é atingido, os objetos menos usados ou obsoletos são expulsos. Os operadores não precisam gerenciar objetos individuais manualmente. O limite de tamanho impede que o cache de um vService afete outros serviços. O tamanho do perfil pode ser aumentado para grandes catálogos de ativos.
Profundidade operacional
O Cache de Resposta deve ser planejado junto com TTL de cache, tamanho de objeto, design de chave, o modelo de invalidação e limites de segurança.
Tamanho do cache
O tamanho máximo para um perfil de cache é definido em MB; até 2048 MB por perfil são suportados. Perfis maiores são adequados para grandes catálogos de ativos; um limite menor é suficiente para pequenos caches de resposta de API.
Timeout mínimo
Um TTL muito curto causa thrashing de cache e diminui o benefício do caching. O TR7 impõe um mínimo de 10 segundos para prevenir ciclos desnecessários de preenchimento e esvaziamento. O TTL deve ser ajustado à frequência de atualização de cada endpoint.
Segurança da chave de cache
Uma chave de cache mal projetada pode retornar conteúdo específico de usuário ou tenant no contexto errado. Quando a diferenciação por tenant, país, tipo de dispositivo ou segmento de usuário é necessária, esses valores devem ser incluídos nas chaves de cache dinâmicas. Endpoints sensíveis devem ser excluídos do caching por padrão.
Comportamento na reinicialização
O cache é baseado em memória; começa vazio quando o dispositivo ou serviço reinicia. Isso elimina a complexidade do cache persistente em disco. O cache aquece novamente com a onda de tráfego inicial.
Atualização baseada em regras
Nenhum endpoint de invalidação em runtime é necessário. O comportamento de cache é gerenciado editando perfis ou regras e acionando um soft reload. Para alterar o comportamento de um endpoint específico, atualize a regra de cache relevante.
Auditoria e operações
Mudanças de perfil de cache, timeout, opção de ignore e chave dinâmica devem ser capturadas no log de auditoria. Quem alterou o comportamento de cache de qual endpoint é visível. Isso é especialmente importante para conformidade e análise de incidentes.
Quando usar
Cache baseado em país para catálogos de produtos de e-commerce
Páginas de produto e APIs de catálogo são cacheadas por um período definido. País é adicionado à chave de cache para que mercados com preços ou níveis de estoque diferentes recebam o conteúdo correto.
Cache de curta duração para respostas de API públicas
Endpoints de notícias, anúncios ou conteúdo público podem ser cacheados por alguns minutos. O ignore de query string impede que parâmetros de rastreamento reduzam a taxa de acertos.
Isolamento por tenant para conteúdo SaaS multi-tenant
ID de tenant ou um header personalizado é adicionado à chave de cache. O mesmo path roteia com segurança para slots de cache separados para diferentes tenants.
Cache controlado de respostas de query GraphQL via POST
Mesmo quando queries GraphQL chegam via POST, queries determinísticas podem ser cacheadas. Hash de corpo ou variáveis FX relevantes são adicionados à chave de cache para minimizar o risco de retornar uma resposta errada.
Descarregando tráfego de ativos estáticos do backend
Arquivos CSS, JS, imagens e fontes são cacheados com um TTL longo. Com ETag ativo, os clientes ignoram o download do corpo completo quando conteúdo não alterado é solicitado.
Cache de renderização separado para mobile e desktop
Família de User-Agent ou classe de dispositivo é adicionada à chave de cache. A mesma URL é mantida em slots de cache separados para mobile e desktop.
Perguntas frequentes
Como headers padrão como Cache-Control e ETag funcionam com o TR7?
Qual é a diferença entre chaves de cache dinâmicas e o header Vary?
Alguns endpoints podem ser cacheados enquanto outros são excluídos dentro do mesmo vService?
Como funciona a invalidação de cache — existe uma API em runtime?
Respostas de POST do GraphQL podem ser cacheadas?
Quais são os valores recomendados para tamanho de cache e timeout?
Reduza a carga do backend com cache de resposta
Perfis de cache, regras condicionais, chaves dinâmicas e opções de substituição em conformidade com RFC para cache de resposta. Vamos percorrer uma configuração ao vivo nos seus próprios serviços.