System Design/02 - Componentes/Caching2 min
CDN Caching
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Cache na borda da rede, geograficamente próximo do usuário. Detalhes de topologia e modelos em Content Delivery Networks, Pull CDNs e Push CDNs.
O que a camada resolve: latência de distância física, carga na origem, e absorção de pico. O que ela adiciona: mais um lugar onde existe uma cópia do dado, com o próprio TTL e a própria política de invalidação.
Cache key — a decisão que faz ou quebra o hit rate
O que diferencia uma entrada de cache: URL, query string e os headers declarados em Vary.
| Cache key inclui | Consequência |
|---|---|
| Só a URL | Hit rate máximo |
| URL + query relevante | Correto para paginação e filtro |
| Cookie | Cada usuário tem sua própria cópia — hit rate perto de zero |
User-Agent completo |
Fragmentação massiva |
Accept-Encoding normalizado |
Correto — separa gzip de brotli |
Normalizar a cache key (ignorar query strings de rastreamento como utm_*, agrupar user agents em classes) é uma das intervenções de maior retorno numa CDN.
Além do cache
CDN moderna também faz terminação TLS, compressão, HTTP/2 e HTTP/3, WAF, Gateway Offloading e computação na borda.
Trade-offs
Conteúdo dinâmico e personalizado ganha pouco com cache de borda — mas ainda ganha com o backbone privado da CDN, que costuma ser mais rápido que a internet pública mesmo sem cache.
O stale-while-revalidate merece destaque: ele serve o conteúdo vencido imediatamente enquanto revalida em background. O usuário nunca espera, e o custo é ver dado alguns segundos desatualizado. Para a maior parte do conteúdo, é o melhor dos dois mundos.
O modo de falha característico é o cache stampede no primeiro acesso de cada borda, tratado em Pull CDNs.
E há o problema de camadas: com cliente, CDN e proxy cacheando, um dado errado pode ficar preso em três lugares com TTLs diferentes. Depurar "por que o usuário ainda vê a versão antiga" exige saber qual camada está servindo.
Exemplo prático
Uma página de produto de e-commerce, aparentemente não cacheável por conter o nome do usuário logado.
A saída é separar: o HTML da página é cacheado na borda sem personalização (max-age=300), e o trecho personalizado — nome, carrinho — é carregado por uma chamada /api/sessao marcada no-store.
O resultado: 95% do peso da página vem da borda com hit alto, e a origem só atende uma requisição pequena por usuário. A alternativa ingênua — marcar a página inteira como não-cacheável — jogaria fora todo o benefício por causa de duas linhas de conteúdo.
Relacionado
Parte de Caching · roadmap.sh/system-design