Cache é uma camada de armazenamento temporário de alta velocidade que mantém cópias de dados frequentemente acessados para reduzir latência e carga sobre sistemas de origem. Presente em processadores, sistemas operacionais, aplicações, bancos de dados, navegadores e redes de distribuição de conteúdo, o cache é um dos mecanismos mais eficientes para escalar aplicações modernas e entregar tempos de resposta em milissegundos, mesmo sob alta demanda.
TL;DR
- O que é: camada rápida que guarda cópias de dados para servir requisições futuras sem recorrer à fonte original.
- Por que importa: reduz latência, economiza recursos de banco de dados e servidor, e melhora escalabilidade e experiência do usuário.
- Quando usar: em qualquer sistema com padrões de leitura repetitivos, consultas caras ou tráfego alto.
Como funciona o Cache?
Cache é um mecanismo de armazenamento temporário que intercepta requisições e serve respostas previamente calculadas em vez de repetir o trabalho. Quando uma aplicação pede um dado, o sistema consulta primeiro o cache; se o dado existe e ainda é válido (cache hit), retorna imediatamente. Se não existe ou expirou (cache miss), busca na fonte original, entrega ao solicitante e armazena a resposta para futuras requisições.
O cache funciona com base em dois princípios: localidade temporal (dados acessados recentemente tendem a ser acessados de novo) e localidade espacial (dados vizinhos costumam ser requisitados juntos). Segundo a Cloudflare (2024), aplicações web bem cacheadas conseguem servir mais de 70% das requisições diretamente da borda, sem tocar no servidor de origem.
Níveis de Cache
O cache existe em múltiplas camadas do stack tecnológico, cada uma com sua função e velocidade específica.
Cache de CPU (L1, L2, L3)
Memória SRAM integrada ao processador. O L1 tem latência de aproximadamente 1 nanossegundo e capacidade de dezenas de KB por núcleo. O L2 fica entre 3 e 10 nanossegundos, e o L3, compartilhado entre núcleos, gira em torno de 40 nanossegundos com dezenas de MB.
Cache de RAM e page cache
O sistema operacional mantém páginas de disco em RAM para acelerar leituras subsequentes. O Linux usa page cache agressivamente: qualquer memória livre é usada para cachear arquivos acessados, liberada automaticamente quando processos precisam de RAM.
Cache de disco
SSDs e HDDs possuem cache interno (DRAM ou SLC) que absorve escritas e acelera leituras. Segundo a Statista (2024), SSDs enterprise com cache de gravação chegam a latências de 50 microssegundos.
Cache de aplicação
Sistemas como Redis e Memcached armazenam objetos, resultados de consultas e sessões em memória. O Redis serve mais de 100 mil operações por segundo em hardware modesto, segundo a Redis Labs (2024).
Cache de browser
Navegadores guardam CSS, JS, imagens e fontes localmente. Cabeçalhos HTTP como Cache-Control, ETag e Last-Modified controlam quanto tempo o browser mantém o recurso antes de revalidar com o servidor.
Cache de CDN (edge cache)
Redes como Cloudflare, Akamai e Fastly replicam conteúdo em centenas de pontos de presença ao redor do mundo. Segundo a Akamai (2024), uma requisição servida da borda entrega resposta em menos de 30 milissegundos em regiões metropolitanas.
Estratégias de cacheamento
A estratégia define como cache e fonte original se coordenam em leituras e escritas. As cinco principais abordagens são:
- Cache-aside (lazy loading): a aplicação consulta o cache primeiro; se não encontra, busca no banco, retorna e grava no cache. É o padrão mais comum com Redis.
- Write-through: toda escrita passa simultaneamente pelo cache e pelo banco. Garante consistência, mas adiciona latência às escritas.
- Write-behind (write-back): escritas vão ao cache primeiro e são replicadas ao banco de forma assíncrona. Alta performance, mas risco de perda em falhas.
- Read-through: o cache é responsável por buscar da origem quando há miss, abstraindo essa lógica da aplicação.
- Refresh-ahead: o cache renova proativamente entradas próximas de expirar, evitando misses em dados quentes.
Cache vs Buffer vs CDN
| Característica | Cache | Buffer | CDN |
|---|---|---|---|
| Propósito | Reduzir latência em leituras repetidas | Suavizar diferença de velocidade entre produtor e consumidor | Distribuir conteúdo geograficamente |
| Latência típica | Nanossegundos a milissegundos | Microssegundos | 10 a 50 milissegundos |
| Política de evicção | LRU, LFU, TTL | FIFO (fila) | TTL + purge sob demanda |
| Escopo | Local ou distribuído | Local ao processo | Global, na borda |
| Casos de uso | Consultas, sessões, objetos | Streaming, I/O de disco | Estáticos, HTML, APIs |
Cache Invalidation: o problema difícil
Phil Karlton, engenheiro da Netscape, cunhou a frase clássica: existem apenas dois problemas difíceis em ciência da computação, nomear coisas e invalidação de cache. Servir dados desatualizados quebra confiança e gera bugs sutis. As principais técnicas são:
- TTL (time-to-live): cada entrada expira após um período pré-definido. Simples, mas cego a mudanças na fonte.
- Event-based: quando o dado muda na origem, um evento (webhook, pub/sub) invalida a chave correspondente no cache. Exige integração cuidadosa.
- Tag-based: chaves recebem tags; invalidar uma tag remove todas as entradas relacionadas de uma vez. Cloudflare e Fastly oferecem essa funcionalidade nativamente.
- Versionamento: a chave inclui uma versão do recurso (ex: ‘produto:123:v7’). Nova versão gera chave nova, deixando a antiga expirar naturalmente.
Exemplos práticos B2B brasileiros
WordPress corporativo com Redis Object Cache
Uma indústria brasileira com blog corporativo enfrentava tempos de resposta de 1,2 segundo em páginas de produtos técnicos. Ao instalar Redis Object Cache no WordPress, consultas repetidas ao MySQL passaram a ser servidas da memória, reduzindo o TTFB para 180 milissegundos, uma queda de 85%.
WooCommerce com Varnish e CDN
Um e-commerce B2B de autopeças com catálogo de 12 mil SKUs configurou Varnish como cache HTTP na frente do WooCommerce. Páginas de produto passaram a ser servidas em 40 milissegundos, e a integração com Cloudflare distribuiu esse cache globalmente. Resultado: capacidade de suportar picos de 30 mil visitas simultâneas em campanhas sem escalar o servidor.
API pública com cache em múltiplas camadas
Uma fintech B2B expõe API REST para parceiros. Configurou cache em três níveis: Redis para respostas de banco (TTL 5 minutos), NGINX para respostas HTTP idempotentes (TTL 60 segundos) e Cloudflare para respostas GET públicas (TTL 30 segundos). Segundo métricas internas, 89% das requisições nunca chegam ao backend.
Cache no WordPress
O WordPress oferece cache em duas camadas principais:
- Object Cache: armazena resultados de consultas ao banco (opções, meta, transients) em memória. Habilitado via Redis, Memcached ou APCu.
- Page Cache: serve páginas HTML já renderizadas sem executar PHP. Plugins populares incluem W3 Total Cache, WP Rocket e LiteSpeed Cache.
Segundo o WP Rocket (2024), sites com page cache adequadamente configurado carregam entre 3 e 5 vezes mais rápido do que sites sem cache.
Ferramentas populares de Cache
- Redis: banco de dados em memória com estruturas ricas (strings, hashes, listas, sets). Ideal para cache de aplicação e pub/sub.
- Memcached: cache distribuído simples e rápido, focado em chave-valor.
- Varnish: proxy reverso de cache HTTP, extremamente performático para conteúdo dinâmico.
- NGINX cache: módulo nativo do NGINX para cachear respostas de upstream.
- Cloudflare e Fastly: CDNs com cache global, purge por API e regras avançadas.
Erros comuns em Cache
- Ignorar cache miss em cascata: quando o cache cai, todas as requisições vão ao banco simultaneamente (thundering herd). Solução: locks distribuídos ou refresh-ahead.
- Servir dados obsoletos (stale data): falta de invalidação após atualização gera respostas desatualizadas por horas.
- Memory bloat: cache cresce sem controle e consome toda a RAM. Definir maxmemory e política de evicção (LRU) é essencial.
- Sem monitoramento: não medir hit rate impede otimização. Um cache com hit rate abaixo de 80% pode estar mal dimensionado.
- Estratégia inexistente: instalar cache sem definir chaves, TTLs e invalidação leva a inconsistências difíceis de debugar.
Como implementar Cache — passo a passo
- Meça antes: identifique consultas caras e endpoints lentos com APM (New Relic, Datadog).
- Escolha o nível: browser, CDN, aplicação ou banco, conforme o tipo de dado.
- Defina chaves: convenção clara (ex: ‘user:123:profile’) que facilite invalidação.
- Configure TTL: comece conservador (segundos a minutos) e ajuste conforme padrão de atualização.
- Implemente invalidação: escolha entre TTL, event-based ou versionamento antes de subir para produção.
- Monitore hit rate: meta acima de 80% para caches de leitura pesada.
- Teste falhas: simule queda do cache e valide que a aplicação degrada graciosamente.
Cache e a Shiftmind
A Shiftmind projeta infraestrutura de cache multicamadas para aplicações WordPress, e-commerces e APIs corporativas. Nossa Hospedagem WordPress inclui Redis Object Cache, page cache e integração com CDN Cloudflare em todos os planos. Para projetos de alta demanda, o Servidor Dedicado permite configurar Varnish, NGINX cache e Redis Cluster em topologias customizadas. Nosso serviço de Suporte e Manutenção WordPress inclui auditoria de performance, monitoramento de hit rate e otimização contínua. Para novos projetos, a Criação de Sites WordPress já entrega cache configurado desde o dia um, e nossa Segurança de Websites garante que o cache não vire vetor para servir conteúdo comprometido.
Perguntas frequentes sobre Cache
Qual a diferença entre cache e memória RAM?
RAM é a memória principal do computador onde processos executam. Cache é um subconjunto especializado dessa memória (ou memória ainda mais rápida, no caso de L1/L2/L3) dedicado a manter cópias de dados frequentemente acessados. Todo cache de aplicação usa RAM, mas nem toda RAM é cache: parte dela guarda código executável, pilha, heap e outros dados de trabalho do processo.
Cache pode piorar a performance?
Sim, se mal configurado. Cache com hit rate baixo adiciona latência sem benefício, pois toda requisição consulta o cache antes de ir à fonte. Cache que consome toda a RAM força swap para disco, degradando o sistema inteiro. Cache com invalidação quebrada serve dados errados, gerando bugs. Bom cache exige medir hit rate, definir política de evicção e monitorar consumo de memória.
Quanto tempo devo manter dados no cache?
Depende do padrão de atualização e tolerância a dados obsoletos. Conteúdo estático (imagens, CSS, JS) pode ter TTL de dias ou meses com versionamento por hash. Páginas HTML de blog podem ficar horas em cache. Dados de e-commerce (preço, estoque) exigem TTL curto (segundos) ou invalidação por evento. A regra prática é: comece conservador e aumente o TTL conforme confiança.
Redis ou Memcached: qual escolher?
Redis oferece estruturas de dados ricas (listas, sets, hashes, sorted sets), persistência opcional, replicação e pub/sub, sendo ideal para casos além de cache simples. Memcached é mais leve, puramente em memória e otimizado para chave-valor simples com múltiplas threads. Para a maioria das aplicações WordPress e web modernas, Redis é a escolha padrão devido à sua versatilidade.
Cache resolve problemas de banco de dados lento?
Cache alivia sintomas mas não corrige causas. Se o banco está lento por falta de índices, queries mal escritas ou schema ruim, o cache mascara o problema até que precise ser reconstruído (falha, deploy, invalidação em massa). O correto é otimizar o banco primeiro e usar cache como camada adicional de performance, não como solução única para gargalos estruturais.
Como sei se meu cache está funcionando?
Meça o hit rate: percentual de requisições servidas do cache versus total. Redis mostra isso via INFO stats (keyspace_hits e keyspace_misses). Varnish tem varnishstat. CDNs expõem dashboards com cache hit ratio. Meta saudável é acima de 80% para caches de leitura pesada. Também monitore latência antes e depois do cache e uso de memória para evitar bloat.
Termos relacionados
Conclusão
Cache é uma das ferramentas mais poderosas para escalar aplicações web e reduzir custos de infraestrutura. Do L1 na CPU ao edge da CDN, cada camada resolve um tipo específico de gargalo. O sucesso depende menos da ferramenta escolhida e mais de estratégia clara: definir chaves, TTLs, invalidação e monitoramento desde o início. Aplicações que tratam cache como cidadão de primeira classe entregam experiências mais rápidas, suportam mais usuários e gastam menos com servidores.
Última atualização: Setembro/2026
Precisa acelerar sua aplicação web com estratégia de cache profissional? A Shiftmind projeta e opera infraestrutura de alta performance para WordPress, e-commerce e APIs. Fale com nossos especialistas.
