Vercel unifica Data Cache e Runtime Cache sem exigir mudança de código

A Vercel anunciou, em post no blog oficial, que está consolidando dois produtos de cache que até agora viviam separados: o Data Cache, usado desde o lançamento do App Router do Next.js↳Next.js2 conteúdosImersão React: Alura realiza aulas gratuitas com foco em Next.JSGestão Dev & TI · jan 2021Criando sua primeira aplicação com RemixDev (Back & Front) · set 2024Ver tudo em Dev (Back & Front) → para alimentar fetch com cache e unstable_cache, e o Runtime Cache, introduzido no ano passado como uma API genérica (getCache, do pacote @vercel/functions) para qualquer framework. A partir de agora, as quatro portas de entrada (fetch com cache, unstable_cache, getCache e a diretiva 'use cache: remote' do Next.js) passam a usar a mesma infraestrutura de armazenamento.

Para quem já tem código em produção, a promessa da Vercel é clara: nada muda na superfície. Se o projeto usa fetch com a opção de cache do Next.js ou chama unstable_cache, o comportamento observável continua o mesmo. O que muda é o que está por trás da chamada, e isso tem efeito direto em budget de armazenamento, billing e nas ferramentas de observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → que o time usa para investigar comportamento de cache.

Por que existiam dois produtos

O Data Cache nasceu amarrado ao App Router: ele guarda os dados que a aplicação usa para montar uma resposta, não a resposta HTTP completa. É a diferença entre cachear o payload de um catálogo de produtos e cachear a página inteira já renderizada (isso é trabalho do CDN caching, outro produto da Vercel). Uma página de produto, por exemplo, pode reaproveitar dados de catálogo do cache enquanto ainda personaliza a resposta final para cada visitante.

O problema é que essa arquitetura só fazia sentido dentro do Next.js. A Vercel queria oferecer o mesmo serviço para quem usa SvelteKit, Nuxt ou qualquer outro stack rodando na plataforma, daí o Runtime Cache, com uma API direta e sem acoplamento a framework. Hoje ele já é usado para lookup de feature flags em Routing Middleware, para cachear conteúdo de CMS durante build e, dentro do próprio Next.js, para alimentar 'use cache: remote'.

Como o Runtime Cache funciona por baixo

A Vercel detalhou a engenharia que sustenta o produto, e os números dão uma ideia de escala: uma API em Go, atrás de fleets de Redis em cada região da plataforma, processa mais de 440 milhões de leituras por hora e movimenta mais de 18 TB de dados no mesmo período.

O desenho é regional e simples na superfície:

• Cada região tem seu próprio cache; um cache hit custa um round trip ao serviço na região onde o código roda.
• Em um cache miss, a aplicação busca ou computa o valor e escreve na região local, sem checar outras regiões.
• A autenticação usa credenciais de curta duração geradas pela própria Vercel, então não há chave de API para gerenciar.
• Cada entrada guarda suas tags e o horário de escrita; invalidar uma tag grava um único timestamp, mesmo que um milhão de entradas compartilhem essa tag.

Esse último ponto é o que torna a invalidação por tag barata: em vez de localizar e apagar entradas uma a uma, o serviço só compara o timestamp de escrita de cada entrada com o timestamp de invalidação da tag correspondente, guardado num tag store separado na mesma região. Se a tag foi invalidada depois que a entrada foi escrita, ela é considerada stale. A propagação desse timestamp para outras regiões usa a mesma infraestrutura de push global que o CDN da Vercel já usa, e normalmente leva algumas centenas de milissegundos para chegar a todas as regiões.

O que a Vercel já otimizou antes de anunciar a fusão

Antes de juntar os dois produtos, a Vercel passou o último ano ajustando o Runtime Cache, e vale entender essas mudanças porque elas valem para todo cache que migrar para lá.

Leitura sob rajada de tráfego. Checar se uma entrada ainda é fresh adiciona uma dependência a cada cache hit: se um shard do tag store ficar lento, ele atrasa leituras mesmo quando o valor cacheado já estava disponível. A Vercel implementou circuit breakers que deixam a leitura usar timestamps de freshness guardados em memória quando o shard está lento, evitando a espera. O efeito colateral é que, durante esse fallback, uma leitura pode tratar como fresh um dado que acabou de ser invalidado há poucos instantes.

Esses breakers foram habilitados em todas as regiões em agosto. Segundo a Vercel, nas rajadas mais pesadas na maior região da plataforma, a latência p99 do serviço de cache caiu para cerca de um quinto do nível anterior em tráfego comparável, e os alertas de on-call para esse tipo de falha pararam de disparar.

Mais espaço, menos eviction. Os budgets de armazenamento do Runtime Cache subiram para projetos Pro em junho e para Enterprise em outubro. Entre projetos Enterprise que sofriam evictions frequentes, a taxa de cache miss caiu pela metade em um dia, segundo os dados publicados pela empresa.

Mais visibilidade. A aba de Runtime Cache na Observability da Vercel ganhou marcadores de deploy, causas de revalidação e utilização de escrita, úteis para comparar mudanças de comportamento de cache com releases e identificar dados que são escritos no cache mas raramente lidos.

O que muda (e o que não muda) na prática

A tabela resume o antes e o depois para quem mantém uma stack Next.js em produção na Vercel:

O ponto que merece atenção de quem administra billing é a última linha: leituras e escritas do Data Cache que antes não eram cobradas passam a seguir o modelo de preço do Runtime Cache. A Vercel diz que times existentes vão receber detalhes de migração e cobrança com antecedência, e que novos times já nascem usando o Runtime Cache por padrão.

Onde isso pesa na estratégia de cache

Para um time que já usa unstable_cache com tags bem definidas, a migração é essencialmente transparente, e o ganho real é o aumento de budget: um pool de armazenamento por projeto e ambiente (em vez de um pool compartilhado por toda a equipe) tende a reduzir o cenário mais comum de dor em produção, que é a aplicação perder dados cacheados por falta de espaço justamente no pico de tráfego.

Vale, no entanto, ler o guia de otimização que a Vercel publicou junto com o changelog antes de assumir que o aumento de budget resolve tudo: se a aplicação escreve no cache mais do que lê, o problema não é tamanho de pool, é estratégia de tag e de revalidação. A nova aba de write utilization na Observability existe justamente para expor esse tipo de desperdício, que passava despercebido quando o Data Cache não cobrava pelas escritas.

Fica também um ponto de atenção arquitetural: o fallback por circuit breaker, que melhora latência p99 em rajadas, tem como trade-off aceitar brevemente dados como frescos mesmo depois de invalidados. Para a maioria das aplicações isso é inofensivo, mas times com requisitos fortes de consistência depois de uma invalidação de tag (por exemplo, um painel de preços que não pode mostrar valor desatualizado nem por alguns milissegundos) devem considerar esse comportamento ao desenhar quais dados colocam atrás de tags compartilhadas.

Fonte: Vercel Changelog