Minhas notas sobre `Cache-Control: max-age=3, must-revalidate`

Eu estava estudando o header Cache-Control: max-age=3, must-revalidate, então resolvi organizar meu entendimento antes de esquecer.

Essa configuração significa: “usar o cache por apenas três segundos e, depois que ele expirar, sempre validar novamente no servidor de origem”. Essa abordagem costuma ser chamada de micro-caching. Ela é muito usada para proteger o servidor contra picos repentinos de tráfego, mantendo o conteúdo próximo de tempo real.

O que significa cada diretiva

Vale separar o papel de cada diretiva.

max-age=3

Ela informa ao navegador e ao CDN que esse conteúdo é considerado fresco por apenas três segundos. Durante essa janela, nenhuma requisição vai para a origem. A resposta é entregue imediatamente a partir do cache.

must-revalidate

Depois que esses três segundos passam, o cache deve revalidar com o servidor de origem e não pode servir conteúdo antigo sem confirmação explícita.

Sem essa diretiva, alguns caches ou algumas configurações podem optar por servir conteúdo stale quando a origem está fora do ar. must-revalidate proíbe esse comportamento de forma clara.

Linha do tempo do comportamento

Fica mais fácil entender simulando o que acontece quando um usuário acessa a página.

O ponto principal é o caso 304 Not Modified depois que os três segundos passam. Como o corpo do conteúdo não precisa ser baixado de novo, tanto a largura de banda quanto a latência ficam menores.

Vantagens dessa configuração

Esse header funciona especialmente bem quando a atualização é importante, mas o volume de tráfego também é muito alto. Há três vantagens principais.

Redução forte da carga na origem

Imagine um site recebendo 1.000 requisições por segundo. Com max-age=3, especialmente junto com CDN, a maior parte dessas requisições é absorvida pelo cache e a origem recebe um volume muito menor de validações.

Mesmo um cache de apenas três segundos pode fazer bastante diferença em ambientes de alto tráfego.

Atualização quase em tempo real

O conteúdo novo aparece em no máximo três segundos. Não é tempo real estrito, mas costuma ser um compromisso aceitável em muitos produtos.

Menor risco de mostrar informação desatualizada

Com must-revalidate, o cliente não pode continuar servindo dados antigos silenciosamente depois do vencimento do cache. Quando precisão importa, isso é relevante.

Casos de uso concretos

Tentei pensar em situações em que esse padrão faz sentido.

Casos adequados

• Página inicial e listas de um site de notícias: artigos novos precisam aparecer rápido, mas alguns segundos de atraso são aceitáveis, e picos de tráfego são comuns
• Exibição de estoque em ecommerce: alguns segundos de atraso são toleráveis, mas mostrar um item esgotado como disponível não é aceitável. must-revalidate ajuda nisso
• Landing pages de eventos ou campanhas: depois da publicação pode vir uma onda de tráfego de redes sociais. O micro-caching absorve essa primeira carga e ainda permite atualizações rápidas
• Resumos em dashboards: não exigem a urgência de um gráfico em tempo real, mas devem refletir KPIs recentes. Se o polling ocorre a cada três segundos ou mais, essa configuração combina bem
• Respostas de API do tipo lista: com esse header, o CDN pode cachear a resposta e reduzir a carga do servidor de origem

Casos inadequados

• Assets estáticos como CSS, JS e imagens: mudam pouco. Nomes com hash de arquivo + max-age=31536000,immutable costumam ser melhores
• Páginas de detalhe de posts de blog: normalmente não mudam com frequência depois de publicadas, então um max-age bem maior faz mais sentido
• Chat em tempo real ou WebSocket: HTTP cache não se aplica bem aqui, e até três segundos de atraso já são demais
• Conteúdo específico por usuário: páginas como área do usuário não combinam com cache compartilhado em CDN. Nesses casos vale considerar diretivas como private

Pontos de atenção

Há também alguns trade-offs fáceis de subestimar.

Uma nova requisição a cada três segundos após expirar

Depois de cada janela de três segundos, uma requisição condicional volta a acontecer. Em comparação com valores maiores de max-age, a latência de rede pesa mais. Vale pensar na UX em conexões lentas.

Comportamento offline

Por causa de must-revalidate, se a rede cair ou a origem estiver fora do ar, o cliente provavelmente mostrará erro mesmo que ainda exista um cache expirado. Em outras palavras, essa política diz: “se eu não consigo confirmar a atualização, prefiro falhar a mostrar algo velho”.

Se isso for rígido demais, vale considerar combinações com stale-while-revalidate ou stale-if-error.

Resumo

Cache-Control: max-age=3, must-revalidate é um equilíbrio agressivo para cenários em que a atualização é importante, mas você não quer derrubar o servidor de origem.

O nome “micro-caching” soa maior do que realmente é. Na prática, significa cachear por apenas alguns segundos. Sob tráfego pesado, esses poucos segundos podem gerar um efeito enorme.

Antes de aplicar essa estratégia, confirme se o alvo realmente combina com esse padrão. Em assets estáticos ou páginas que quase não mudam, ela só aumenta requisições desnecessárias de revalidação.