Muita gente usa os dois termos como sinônimos, mas não são. Estudei sobre isso e quero compartilhar com vocês, afinal a melhor forma de aprender é ensinando.
O que é cache
De forma simples, cache é guardar uma cópia de um dado em um lugar mais rápido ou mais perto de quem vai usar, para não precisar buscar de novo na fonte original. Ou seja, você troca espaço (memória ou disco) por velocidade.
Repare que cache é um conceito, não uma ferramenta. Existe cache na CPU, no navegador, no servidor, no banco de dados. E ele funciona porque a gente acessa sempre os mesmos dados: um post viral, o perfil do usuário logado, o logo do site.
Hit e miss
- Hit: o dado estava no cache, e a resposta sai rápido.
- Miss: não estava, então é preciso buscar na fonte original e, normalmente, salvar no cache para a próxima vez.
Num artigo aqui do dev.to com Node + Redis, a primeira requisição (miss, que foi buscar numa API externa) levou 615 ms. A mesma requisição depois de cacheada (hit) levou 3 ms.
TTL (Time To Live)
TTL é quanto tempo um dado vale antes de expirar. Por exemplo, se guardo o perfil de um usuário por 5 minutos e ele troca a foto, os outros podem continuar vendo a foto antiga por até 5 minutos. TTL curto deixa o dado mais fresco, mas gera mais misses; TTL longo dá mais hits, com mais chance de mostrar dado velho.
As camadas de cache
Entre o usuário e o banco de dados existem várias camadas de cache, e cada uma guarda coisas diferentes:
- Navegador
- CDN
- Reverse proxy (NGINX, Varnish)
- Cache de aplicação (Redis, Memcached)
- O próprio banco de dados
Cache-aside
A estratégia mais comum no cache de aplicação é o cache-aside. A aplicação olha primeiro no cache; se der miss, busca no banco, salva no cache e devolve. Num e-commerce, quem abre primeiro o "Tênis X" paga a ida ao banco, e os próximos milhares recebem do Redis.
Nem tudo são flores
"Há só duas coisas difíceis em Ciência da Computação: invalidação de cache e dar nomes às coisas." (frase atribuída a Phil Karlton)
Invalidação. Quando o dado muda na fonte, como fazer o cache esquecer a versão velha?
Cache stampede. Imagine a página inicial de um site de notícias com TTL de 60 segundos. No segundo 61 a chave expira, milhares de requisições dão miss juntas e todas batem no banco. O banco pode cair.
Cachear o que não devia. O erro mais perigoso é guardar num cache compartilhado (proxy ou CDN) uma página com dado de usuário logado. O usuário A abre "Minha conta", a resposta fica cacheada e o usuário B recebe a página com os dados do A. Para isso existe o Cache-Control: private.
O que é CDN
CDN (Content Delivery Network) é uma infraestrutura: uma rede de servidores espalhados pelo mundo que guardam cópias do seu conteúdo perto do usuário. Exemplos: Cloudflare, Amazon CloudFront, Akamai e Fastly.
O problema que ela resolve é físico. O dado viaja por cabos, e distância é latência. Se seu servidor está nos EUA e o usuário está em Manaus, cada imagem, CSS e JS faz essa viagem de ida e volta. Com uma CDN, ele baixa tudo de um servidor no Brasil.
Como funciona
O usuário acessa meusite.com/logo.png e o DNS manda ele para o servidor da CDN mais próximo, o PoP (Point of Presence). Se o PoP tem o arquivo, entrega na hora. Se não tem, busca no seu servidor (a origem), entrega e guarda para os próximos.
Quem diz o que a CDN pode guardar, e por quanto tempo, são os headers que a origem manda:
-
Cache-Control: public, max-age=31536000, immutablepermite guardar por um ano (bom para arquivos com hash no nome). -
Cache-Control: privateproíbe a CDN de guardar. -
ETageLast-Modifiedpermitem perguntar "mudou?" e receber um304 Not Modifiedsem baixar de novo.
Um exemplo grande é a Netflix, que tem a própria CDN, a Open Connect. Ela coloca servidores dentro dos provedores de internet, e o site oficial fala em mais de mil provedores parceiros. Ou seja, a série que você assiste provavelmente vem de dentro do seu provedor.
Então, qual a diferença?
- Cache é o conceito; CDN é uma aplicação dele em escala geográfica.
- O Redis fica perto do servidor; a CDN fica perto do usuário.
- A CDN resolve distância, mas não resolve query lenta no banco.
E eles não são concorrentes: a maioria dos sistemas grandes usa os dois.
Use cache de aplicação para queries pesadas e repetidas, sessões e dados lidos muito e mudados pouco.
Use CDN para usuários espalhados pelo mundo, imagens, JS, CSS, vídeo e picos de tráfego.
Quando NÃO usar cache
- Dado que precisa estar sempre certo na leitura, como saldo ou estoque na hora do pagamento.
- Dado que muda o tempo todo e quase não se repete.
- No começo do projeto, sem gargalo medido: cache cedo demais esconde problema de query.
Conclusão
Apresentei apenas algo introdutório, recomendo se aprofundarem! Se você já é experiente, complementa nos comentários. Obrigado por ler até aqui!
Top comments (0)