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.
O TR7 gerencia o comportamento de cache por meio de quatro camadas: perfis, condições, chaves dinâmicas e substituições controladas.
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.
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.
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.
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.
O Cache de Resposta torna cada comportamento — desde o perfil de cache até a chave dinâmica — configurável no nível de vService.
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.
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.
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.
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.
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.
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.
`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.
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.
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 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 é 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.