trilha

System Design/02 - Componentes/Caching2 min

Web Server Caching

Perguntas-guia
  • Que problema isso resolve?
  • Quando usar / quando NÃO usar?
  • Qual o principal trade-off?
  • Como isso falha em produção?

Conceito

Cache no proxy reverso ou servidor web (nginx, Varnish, Apache) — entre a CDN e a aplicação.

cliente → CDN → [ nginx/Varnish ] → aplicação → banco
                  guarda a resposta

É a última camada antes de acordar a aplicação, e a primeira que você controla inteiramente.

O que ele guarda

  • Resposta HTTP completa (page cache) — a aplicação nem é chamada
  • Fragmento de página (ESI — Edge Side Includes)
  • Arquivo estático, servido direto do disco sem passar pela aplicação
  • Micro-cache: TTL de 1 a 10 segundos, para absorver rajadas

Trade-offs

Micro-caching é a técnica mais subestimada aqui. Cachear por 1 segundo parece inútil e é transformador sob tráfego alto: com 5.000 req/s na mesma URL, um TTL de 1 s reduz a carga na aplicação de 5.000 para 1 requisição por segundo. E a "desatualização" máxima é de 1 segundo — imperceptível para quase todo conteúdo.

stale-while-revalidate e proxy_cache_use_stale cobrem o caso de falha: quando a aplicação cai, o proxy continua servindo a versão vencida em vez de propagar erro. O sistema degrada em frescor, não em disponibilidade.

Request coalescing (proxy_cache_lock no nginx) resolve o stampede local: quando N requisições chegam para a mesma chave em miss, apenas uma vai à aplicação e as outras esperam o resultado.

O custo é que esse cache vive por instância. Com 10 servidores nginx, são 10 caches independentes — 10 misses para popular a mesma chave, e uma invalidação que precisa alcançar todos. Caches compartilhados resolvem isso e reintroduzem um componente central.

Exemplo prático

Uma home page dinâmica que recebe rajadas de tráfego de campanhas.

proxy_cache_valid 200 1s;
proxy_cache_lock on;
proxy_cache_use_stale updating error timeout;

Três linhas. A primeira transforma qualquer pico em no máximo 1 req/s na aplicação. A segunda garante que, num miss simultâneo, só uma requisição atravessa. A terceira mantém o site no ar servindo conteúdo vencido se a aplicação falhar.

O conteúdo pode ficar 1 segundo desatualizado — e a aplicação para de cair sob carga.

Relacionado


Parte de Caching · roadmap.sh/system-design

Buscar

Busca por título, seção e texto das notas