Visão geral

São 9h59 do dia em que um show de estádio abre as vendas. A BoxOffice tem 60.000 lugares para vender e cerca de 2 milhões de fãs com a página do evento aberta, apertando F5. Às 10h00 o serviço catalog recebe dezenas de milhares de requisições GET /events/42 por segundo, e cada uma executa as mesmas três consultas SQL: o evento, o local, a tabela de preços. Os dados não mudam há uma semana. Mesmo assim, o banco do catálogo chega a 100% de CPU, consultas que levavam 3 ms passam a levar 800 ms e o checkout — que compartilha esse banco — começa a dar timeout. Ninguém comprou um ingresso ainda, e o sistema já caiu.

A solução não é um banco maior. É parar de fazer ao banco a mesma pergunta dois milhões de vezes. Isso é cache: guardar uma cópia da resposta a uma pergunta cara em um lugar mais rápido e mais barato de ler, e servir a cópia enquanto ela for boa o suficiente.

Roteiro

1. Esta visão geral — por que o cache funciona, onde os caches ficam, a matemática da taxa de acerto, dimensionamento e o que nunca cachear.
2. Padrões de Cache — cache-aside, read-through, write-through, write-behind, write-around, refresh-ahead; desenho de chaves.
3. Invalidação e Despejo — TTLs, invalidação explícita, a corrida do cache-aside, CDC, LRU/LFU/W-TinyLFU.
4. Modos de Falha — cache frio, stampede, avalanche, penetração, chaves quentes, a queda do cache.
5. Redis — estruturas de dados, atomicidade, persistência, replicação, Redis Cluster, serviços gerenciados.
6. Quiz — verifique seu entendimento.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

Por que o cache funciona

Um cache é uma aposta: o dado que eu li agora será lido de novo em breve. Duas propriedades das cargas reais fazem essa aposta valer a pena.

• Localidade temporal — o que foi lido recentemente tende a ser lido de novo. Um fã que abriu a página do evento vai recarregá-la uma dúzia de vezes antes das 10h00.
• Popularidade concentrada — uma pequena fração dos itens recebe a maior parte das requisições. A BoxOffice lista 100.000 eventos, mas numa sexta à noite algumas centenas deles (os grandes shows, os jogos do fim de semana) levam quase todo o tráfego.

A popularidade na web segue, aproximadamente, uma distribuição do tipo Zipf: o item de posição \(i\) é pedido com probabilidade proporcional a \(1/i^{s}\), onde \(s\) (a concentração, ou skew) costuma ficar entre 0,6 e 1 para objetos web¹. Quanto maior o \(s\), mais concentrado o tráfego, e mais um cache pequeno ajuda.

O segundo ingrediente é a diferença de latência entre as camadas de armazenamento. Os números abaixo são ordens de grandeza — variam com o hardware e a rede, mas o que importa são as razões entre eles²:

Um cache não só torna a leitura mais rápida. Ele também tira trabalho do sistema que está atrás dele: cada acerto (hit) é uma consulta que o banco nunca vê. Na maioria dos sistemas reais, esse segundo efeito — proteger a fonte da verdade — é a razão de o cache existir.

Onde os caches ficam

Uma única requisição da BoxOffice pode ser respondida por seis caches diferentes antes de chegar ao banco. Cada camada está mais perto do usuário (mais rápida, mais barata por acerto), mas guarda menos e é mais difícil de invalidar.

flowchart LR
    U["Navegador / app<br/>cache HTTP"] -->|"miss"| CDN["Borda da CDN<br/>estáticos + páginas públicas"]
    CDN -->|"miss"| GW["API gateway<br/>cache de respostas"]
    GW -->|"miss"| APP["serviço catalog<br/>cache em processo"]
    APP -->|"miss"| R[("Redis<br/>cache distribuído")]
    R -->|"miss"| DB[("PostgreSQL<br/>buffer pool + page cache do SO")]
    DB -->|"linha"| APP
    APP -->|"SET com TTL"| R

Quanto mais profunda a camada, mais consistente ela é: o buffer pool do banco nunca devolve um dado velho, enquanto uma cópia no navegador não pode ser recolhida de jeito nenhum. Escolher onde cachear é, portanto, escolher quanta defasagem cada tipo de dado tolera — o assunto de Invalidação e Despejo. CDNs e cache HTTP são tratados em profundidade em Tráfego e Borda; esta aula se concentra no lado da aplicação: caches em processo e distribuídos.

A matemática da taxa de acerto

A taxa de acerto (hit ratio) \(h\) é a fração de leituras respondidas pelo cache. Duas fórmulas sustentam quase todas as decisões de cache.

Latência efetiva — o tempo médio de uma leitura:

onde \(t_{\text{miss}}\) inclui a consulta frustrada ao cache mais a consulta ao banco (e a escrita de volta no cache).

Carga no banco — as leituras que passam:

O gráfico abaixo mostra os dois efeitos. À esquerda, a taxa de acerto de um cache ideal que sempre guarda os \(k\) itens mais populares, para um catálogo de 100.000 itens e várias concentrações (um cache real, cuja política de despejo precisa adivinhar, se sai um pouco pior). À direita, a carga no banco em função da taxa de acerto para 50.000 leituras por segundo.

Duas lições do painel da esquerda:

• Com concentração forte (\(s \geq 1\)), um cache com 1% do catálogo (linha pontilhada) já responde 60–85% das leituras. Dobrar o cache a partir daí rende só alguns pontos: os retornos diminuem rápido.
• Com concentração fraca (\(s = 0{,}6\), muitos itens com popularidade parecida — por exemplo, uma cauda longa de perfis de usuários), um cache pequeno quase não ajuda. Antes de adicionar um cache, pergunte se o padrão de acesso é concentrado.

Dimensionando um cache

O cache precisa guardar o conjunto de trabalho (working set) — os itens lidos de novo enquanto ainda estão no cache — e não o conjunto de dados inteiro.

Regras práticas de dimensionamento:

• Meça o tamanho do item, não chute: serialize um objeto real e veja o tamanho (MEMORY USAGE chave no Redis).
• Monitore os despejos: se evicted_keys cresce sem parar enquanto a taxa de acerto cai, o cache é pequeno demais para o conjunto de trabalho.
• Separe por finalidade: sessões (não podem ser despejadas) e caches de consultas (podem) não devem disputar a mesma memória — use instâncias ou políticas de despejo diferentes (Redis).

O que não cachear

Um cache responde "qual era o valor um instante atrás?". Algumas perguntas precisam de "qual é o valor agora?".

A mesma lógica vale para saldos de conta, status de pagamento, chaves de idempotência e qualquer coisa em que agir sobre um valor antigo cause uma ação errada e irreversível. Uma boa regra: cacheie o que você exibe, não aquilo sobre o que você decide.

Outras coisas que não devem ir para um cache compartilhado: dados lidos uma única vez (um cache cheio de itens de uma leitura só despeja os úteis), dados pessoais sem TTL claro e sem controle de acesso (um cache é uma cópia que também precisa ser protegida e apagada) e valores que são mais baratos de calcular do que de buscar pela rede.

Veja no playground

Experimente: o cenário abaixo coloca um Redis em cache-aside na frente do banco do catálogo. Inicie a execução com as configurações padrão e observe a taxa de acerto, o QPS do banco e a latência p99. Depois (1) ajuste o TTL do cache para um valor bem curto e veja a taxa de acerto e a carga no banco se moverem juntas; (2) esvazie o cache no meio da execução (cache frio) e veja quanto tempo o p99 leva para se recuperar; (3) aumente a carga até o banco saturar só com as faltas.

Abra o playground completo para adicionar um cache em processo ou uma CDN na frente do mesmo desenho. O componente cache é descrito no catálogo de componentes.

O mapa de conceitos de caching

Um cache não é um componente, e sim uma camada em cada salto: cada componente da paleta no caminho de leitura pode responder a partir de uma cópia antes que a requisição chegue à fonte da verdade. O mapa liga cada componente da paleta (verde) aos conceitos de cache que ele usa (azul):

flowchart LR
    client["client · mobile"]:::comp -->|"miss"| cdn["cdn"]:::comp
    cdn -->|"miss"| apigw["apigw"]:::comp
    apigw -->|"miss"| app["app"]:::comp
    app -->|"miss"| cache["cache"]:::comp
    cache -->|"miss"| sql["sql"]:::comp
    sql -->|"CDC"| stream["stream · pubsub"]:::comp
    stream -->|"invalida"| cache
    client -.- c1["Cache-Control, ETag,<br/>URLs versionadas"]:::tech
    cdn -.- c2["purge por tag,<br/>TTL curto na borda"]:::tech
    app -.- c3["L1 em processo,<br/>cache em dois níveis"]:::tech
    cache -.- c4["cache-aside, TTL, despejo,<br/>taxa de acerto, dimensionamento"]:::tech
    cache -.- c5["stampede, chaves quentes,<br/>o cache cai"]:::tech
    sql -.- c6["buffer pool,<br/>nunca cachear decisões"]:::tech
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Conexões

• Bancos de dados — a fonte da verdade que o cache protege; réplicas de leitura são a outra forma de escalar leituras.
• Tráfego e Borda — DNS e CDN — cache HTTP e CDNs, as camadas de cache mais externas.
• Hands-on 5 — Cache — Redis em cache-aside no serviço catalog; medir a taxa de acerto e o p99; reproduzir e corrigir um stampede.
• Exercício — cache + réplica — medições antes/depois de um cache e de uma réplica de leitura.
• Estudos de caso: cache distribuído, encurtador de URLs, autocompletar de busca.
• Playground — cenário read-heavy-cache.

Pontos-chave

O que quebra em seguida

O caminho de leitura agora é barato: com 95% de acerto o banco vê uma leitura em cada vinte, e o lab 5 mede isso. O caminho de escrita não mudou. O POST /orders ainda reserva o assento, chama o provedor de pagamento e envia o e-mail de confirmação dentro da mesma requisição, então o fã espera o mais lento deles, e uma falha no e-mail vira uma falha nas compras. E nenhum cache ajuda quando 2 milhões de fãs querem comprar, não ler: o banco aguenta cerca de 1.100 reservas/s e chegam 33.000. Tirar o trabalho lento da requisição, e colocar a multidão numa fila justa, é a aula 8 — Mensageria.