Quais são as camadas de cache em um stack web típico?

Question

Accepted Answer

Uma requisição passa por **múltiplas camadas de cache**, cada uma mais próxima do usuário servindo mais rapidamente, mas retendo menos dados. A ideia é responder o mais distante possível (próximo ao cliente) e só cair para a origem quando nada acima puder servir a resposta.

## As camadas, de fora para dentro

```text
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest)                            (closest to data)
```

- **Cache do navegador** — armazena ativos estáticos (JS, CSS, imagens) e respostas cacheáveis no dispositivo do usuário. O TTL é controlado por `Cache-Control`/`ETag`; ativos geralmente recebem TTLs longos (dias–anos) com nomes de arquivo com hash.
- **CDN** (CloudFront, Cloudflare) — cacheia conteúdo estático e às vezes dinâmico em nós de borda próximos aos usuários. TTLs de minutos (HTML) até um ano (ativos imutáveis).
- **Reverse proxy** (Varnish, nginx) — cacheia páginas completas ou fragmentos na frente da aplicação. TTLs de segundos a minutos para páginas hot; suporta purga em caso de mudança.
- **Cache de aplicação / objeto** (Redis, Memcached) — cacheia resultados computados, resultados de consultas ao BD, sessões, fragmentos renderizados. TTLs de segundos a horas, mais invalidação explícita.
- **OPcache** — cacheia **bytecode PHP compilado** na memória para que scripts não sejam re-parseados por requisição. Efetivamente persistente até deploy de código.
- **Cache de query / buffer do BD** — o banco de dados mantém páginas hot e (em alguns engines) resultados de queries na memória, evitando leituras de disco.

## Como raciocinar sobre elas

```text
for each layer outward → inward:
  if layer has fresh copy → return it (stop here)   // a hit; cheapest possible
  else → ask the next layer in                      // a miss; falls through
origin (app + DB) → does the real work, fills caches on the way back out
```

Cada camada troca **frescor por velocidade**: camadas externas são mais rápidas mas mais propensas a ficar stale, então coloque TTLs longos + hash de conteúdo em coisas realmente estáticas e TTLs curtos + invalidação em coisas dinâmicas.

## Por que isso importa

A maioria da redução de latência e carga em um stack web vem de cache na camada certa. Saber o que cada camada retém e seu TTL típico permite colocar um cache onde realmente ajuda, evitar servir dados stale, e raciocinar sobre por que uma mudança não apareceu (qual camada ainda está servindo uma cópia antiga).