Estratégias de cache: cache Redis, CDN e HTTP para aplicativos da web

O armazenamento em cache é a técnica mais eficaz para melhorar o desempenho do aplicativo. Um cache bem projetado pode reduzir a carga do banco de dados em 90%, reduzir os tempos de resposta de 200 ms para 2 ms e economizar milhares de dólares em custos de infraestrutura mensalmente. No entanto, o cache também é uma das áreas mais incompreendidas da engenharia de software – bugs de invalidação criam dados obsoletos, debandadas de cache derrubam servidores e TTLs mal escolhidos desperdiçam memória ou fornecem conteúdo desatualizado.

Principais conclusões

• Projetar cache em camadas: navegador para CDN, aplicativo (Redis) para cache de consulta de banco de dados - cada camada lida com diferentes características de dados
• O padrão Redis cache-aside é o padrão mais seguro: ler do cache, retornar ao banco de dados, preencher o cache em caso de falha
• Os cabeçalhos de cache HTTP (Cache-Control, ETag, Vary) eliminam totalmente as solicitações desnecessárias - a solicitação mais rápida é aquela que nunca chega ao seu servidor
• A invalidação do cache é mais difícil do que o armazenamento em cache - use a expiração baseada em TTL como estratégia principal e a invalidação orientada a eventos para atualização de dados críticos

---

A hierarquia do cache

O cache eficaz funciona em camadas, com cada camada otimizada para diferentes requisitos de latência, capacidade e atualização.

Camada 1: Cache do Navegador

O cache do navegador é o cache mais rápido e barato porque elimina totalmente a solicitação de rede. Os cabeçalhos HTTP Cache-Control controlam o comportamento de cache do navegador.

Para ativos estáticos com nomes de arquivos com hash de conteúdo (como saída de compilação Next.js), defina Cache-Control: public, max-age=31536000, immutable. O hash de conteúdo no nome do arquivo garante que o conteúdo alterado receba um novo URL, para que você possa armazenar em cache de forma agressiva sem se preocupar com conteúdo desatualizado.

Para páginas HTML e respostas de API, use TTLs mais curtos com revalidação: Cache-Control: public, max-age=60, stale-while-revalidate=300. Isso veicula conteúdo em cache por 60 segundos e, em seguida, é revalidado em segundo plano, continuando a veicular conteúdo desatualizado por até 5 minutos.

Camada 2: Cache de borda CDN

Uma CDN armazena conteúdo em servidores de borda distribuídos globalmente, reduzindo a latência ao servir conteúdo do local mais próximo de cada usuário. Para uma base de usuários global, o cache CDN reduz a latência média de 200-500 ms (ida e volta do servidor de origem) para 10-50 ms (borda mais próxima).

O que armazenar em cache no CDN:

• Todos os ativos estáticos (JavaScript, CSS, imagens, fontes)
• Páginas de marketing público (com TTL curto para atualização de conteúdo)
• Páginas do catálogo de produtos (TTL de 5 a 15 minutos para comércio eletrônico)
• Respostas de API para dados públicos (listas de produtos, conteúdo de blog)

O que NÃO armazenar em cache no CDN:

• Respostas API autenticadas (dados específicos do usuário)
• Carrinho de compras e páginas de checkout
• Páginas do painel de administração
• Terminais de webhook
• Qualquer resposta com cabeçalhos Set-Cookie

Camada 3: Cache de Aplicativo (Redis)

O Redis fornece acesso com latência de microssegundos a dados armazenados em cache, tornando-o ideal para dados caros para serem computados ou acessados ​​com frequência. Ao contrário do cache CDN, o Redis pode armazenar em cache dados autenticados e específicos do usuário porque seu aplicativo controla o acesso.

Camada 4: Cache de consulta de banco de dados

O PostgreSQL mantém um cache de buffer (shared_buffers) que armazena em cache tabelas e páginas de índice acessadas com frequência na memória. Embora não seja diretamente controlável por consulta, a configuração adequada garante que os dados importantes permaneçam na memória. Para consultas de relatórios, considere visualizações materializadas que pré-calculam agregações caras.

---

Padrões de cache Redis

Redis é o cache em nível de aplicativo mais popular para aplicativos da web, suportando strings, hashes, listas, conjuntos, conjuntos classificados e fluxos. O padrão que você escolhe determina como seu cache se comporta em casos extremos.

Cache-Aside (carregamento lento)

Cache-aside é o padrão padrão mais seguro. O aplicativo verifica primeiro o Redis. Em uma ocorrência no cache, ele retorna os dados armazenados em cache. Em caso de falta de cache, ele consulta o banco de dados, armazena o resultado no Redis com um TTL e retorna os dados.

Vantagens:

• Apenas os dados solicitados são armazenados em cache (sem desperdício de memória em dados não utilizados)
• A falha do banco de dados afeta apenas as falhas de cache, não as ocorrências de cache
• Simples de implementar e raciocinar sobre

Desvantagens:

• A primeira solicitação de cada chave sempre atinge o banco de dados (inicialização a frio)
• Dados obsoletos possíveis entre a atualização do banco de dados e a expiração do cache

Gravação

No cache write-through, cada gravação no banco de dados também atualiza o cache imediatamente. O aplicativo grava no banco de dados e no Redis na mesma operação.

Vantagens:

• O cache está sempre atualizado – sem janela de dados obsoleta
• O desempenho de leitura é sempre rápido (sem falhas de cache após a gravação inicial)

Desvantagens:

• A latência de gravação aumenta (duas gravações por operação)
• O cache pode conter dados que nunca são lidos (memória desperdiçada)
• Requer tratamento cuidadoso de erros quando uma gravação é bem-sucedida e a outra falha

Write-Behind (escrever de volta)

O cache write-behind grava no Redis imediatamente, mas adia a gravação do banco de dados para um processo em segundo plano. Isso reduz a latência de gravação, mas apresenta o risco de perda de dados se o Redis falhar antes da conclusão da gravação do banco de dados.

Use com moderação – esse padrão é apropriado para contadores analíticos, limitação de taxa e dados de sessão onde a perda ocasional de dados é aceitável, e não para transações financeiras ou contagens de inventário.

Prevenção de debandada de cache

Uma debandada de cache ocorre quando uma chave de cache popular expira e centenas de solicitações simultâneas consultam o banco de dados simultaneamente para reconstruí-lo. Isso pode sobrecarregar o banco de dados.

Estratégias de prevenção:

1. Stale-while-revalidate – fornece dados ligeiramente obsoletos enquanto uma solicitação reconstrói o cache em segundo plano
2. Bloqueio mutex – use Redis SETNX para garantir que apenas uma solicitação reconstrua o cache enquanto outras esperam ou fornecem dados obsoletos
3. Expiração antecipada probabilística – recalcula aleatoriamente antes da expiração do TTL, distribuindo as reconstruções ao longo do tempo em vez de concentrá-las na expiração

---

Design de estratégia TTL

Os valores de tempo de vida (TTL) determinam quanto tempo os dados permanecem no cache. Muito curto e você terá perdas excessivas de cache. Muito tempo e você fornece dados obsoletos.

TTL deslizante vs TTL fixo

O TTL fixo expira a chave em um horário definido após a criação. Deslizar o TTL redefine a expiração sempre que a chave é acessada. Use TTL deslizante para dados de sessão (mantenha sessões ativas ativas) e TTL fixo para caches de conteúdo (garanta atualização regular da fonte).

---

Aprofundamento dos cabeçalhos de cache HTTP

O cache HTTP é poderoso porque funciona em todas as camadas: navegador, CDN, proxies e balanceadores de carga, todos entendem os mesmos cabeçalhos.

Diretivas de controle de cache

• public -- qualquer cache (navegador, CDN, proxy) pode armazenar a resposta
• privado -- apenas o navegador pode armazenar em cache (não CDN ou proxies) -- use para respostas autenticadas
• no-cache - armazena em cache a resposta, mas revalida com o servidor antes de usá-la (nome enganoso - armazena em cache)
• no-store – não armazena em cache (dados confidenciais, como páginas bancárias)
• max-age=N – o cache é válido por N segundos
• s-maxage=N -- Duração do cache CDN/proxy (substitui a idade máxima para caches compartilhados)
• stale-while-revalidate=N – exibe conteúdo obsoleto por N segundos enquanto revalida em segundo plano
• imutável – o conteúdo nunca será alterado (use com URLs com hash de conteúdo)

ETag e solicitações condicionais

ETags fornecem validação de cache baseada em conteúdo. O servidor gera um hash do conteúdo da resposta e o envia como cabeçalho ETag. Nas solicitações subsequentes, o navegador envia a ETag em um cabeçalho If-None-Match. Se o conteúdo não foi alterado, o servidor responde com 304 Not Modified (no body), economizando largura de banda.

Use ETags para respostas de API onde o conteúdo muda de forma imprevisível e o cache baseado em TTL seria muito agressivo ou muito conservador.

Variar cabeçalho

O cabeçalho Vary informa aos caches que a resposta depende de cabeçalhos de solicitação específicos. Por exemplo, Vary: Accept-Encoding significa que as versões gzip e Brotli são armazenadas em cache separadamente. Vary: Accept-Language armazena em cache diferentes versões de idiomas separadamente.

Tenha cuidado com Vary – cada combinação única de cabeçalhos variados cria uma entrada de cache separada. Vary: Cookie desativa efetivamente o cache porque cada usuário possui cookies diferentes.

---

Estratégias de invalidação de cache

A invalidação de cache é notoriamente um dos dois problemas difíceis da ciência da computação. O objetivo é remover ou atualizar os dados armazenados em cache quando os dados de origem são alterados, sem introduzir leituras obsoletas ou perdas desnecessárias de cache.

Expiração baseada em TTL

A estratégia de invalidação mais simples e confiável. Defina um TTL em cada chave armazenada em cache e aceite que os dados podem estar ligeiramente obsoletos na janela TTL. Para a maioria dos casos de uso, um TTL de 5 minutos oferece um excelente equilíbrio entre atualização e desempenho.

Invalidação baseada em eventos

Quando um registro de banco de dados for alterado, publique um evento que acione a exclusão do cache. Isso fornece atualização quase instantânea, mas adiciona complexidade e modos de falha. Se o evento for perdido (problema de rede, falha na fila), o cache servirá dados obsoletos até que o TTL expire.

Use a invalidação orientada a eventos para dados críticos, como contagens de estoque e preços, e conte com o TTL para todo o resto.

Invalidação baseada em tags

Alguns sistemas de cache suportam a marcação de entradas de cache com rótulos. Quando você invalida uma tag, todas as entradas com essa tag são eliminadas. Isto é útil para invalidar todos os dados armazenados em cache relacionados a uma entidade específica (por exemplo, todos os caches relacionados a produtos quando um catálogo de produtos é atualizado).

---

Perguntas frequentes

Como decido o que armazenar em cache?

Armazene em cache dados que são lidos com frequência, caros para calcular e tolerantes a breves inatividades. Páginas de catálogo de produtos, permissões de usuário, métricas de painel computadas e dados de configuração são excelentes candidatos. Carrinhos de compras, contagens de inventário em tempo real e transações financeiras geralmente não devem ser armazenados em cache ou devem usar TTLs muito curtos com invalidação orientada por eventos.

O que acontece quando o Redis cai?

Com o padrão cache-aside, seu aplicativo volta a consultar o banco de dados diretamente. Os tempos de resposta aumentam, mas o aplicativo permanece funcional. Projete seu aplicativo para lidar com falhas de cache normalmente – o Redis deve ser uma otimização de desempenho, não um ponto único de falha.

Quanta memória devo alocar para o Redis?

Monitore a taxa de acertos do cache e o uso de memória. Uma taxa de acerto acima de 95% com utilização de memória abaixo de 80% indica um bom dimensionamento. Se a taxa de acertos cair abaixo de 90%, você precisará de mais memória ou seus TTLs serão muito curtos. Comece com 1 a 2 GB para a maioria dos aplicativos e dimensione com base nos dados de monitoramento.

Devo usar Redis ou Memcached?

Redis é a melhor escolha padrão para a maioria dos aplicativos. Ele suporta mais tipos de dados, opções de persistência, pub/sub para invalidação orientada a eventos e script Lua para operações atômicas. O Memcached é mais simples e um pouco mais rápido para armazenamento em cache de valor-chave puro em escala extrema, mas o Redis cobre mais casos de uso.

Como evito o fornecimento de dados obsoletos após uma implantação?

Inclua um identificador de versão nas chaves de cache (por exemplo, chaves de prefixo com a versão de implantação ou uma versão do esquema). Quando você implanta, a nova versão usa novas chaves de cache, e as chaves antigas expiram naturalmente via TTL. Como alternativa, libere todo o cache na implantação se seu aplicativo lidar com caches frios normalmente.

---

O que vem a seguir

Comece implementando cabeçalhos de cache HTTP para seus ativos estáticos e páginas públicas – isso fornece melhoria imediata de desempenho sem nenhuma alteração no aplicativo. Em seguida, adicione o cache Redis para suas consultas de banco de dados e endpoints de API mais caros.

Para obter uma visão completa da otimização de desempenho, consulte nosso guia de pilares sobre escalonamento de sua plataforma de negócios. Para otimizar a fonte de dados que alimenta seu cache, leia nosso guia sobre otimização de consulta de banco de dados.

ECOSIRE implementa arquiteturas de cache para plataformas executadas em Odoo ERP e Shopify. Entre em contato com nossa equipe para uma revisão da estratégia de cache.

---

Publicado por ECOSIRE — ajudando empresas a escalar com soluções baseadas em IA em Odoo ERP, Shopify eCommerce e OpenClaw AI.