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

Question

IT Interview Practice · 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).

As camadas, de fora para dentro

Como raciocinar sobre elas

Por que isso importa

Perguntas relacionadas