Case: distributed cache (Redis/Memcached)
- ⬜🔔 Case: sistema de notificações em escala(System Design Interview Prep)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
O problema que o hash comum não resolve
Distribuir chaves entre N servidores parece trivial: hash(chave) módulo N. E funciona — até N mudar. Adicione um servidor e o divisor vira N+1: quase toda chave passa a mapear para outro lugar, e o cache inteiro perde o efeito de uma vez.
# Hash módulo N — o que acontece ao crescer de 4 para 5 servidores
hash("user:42") % 4 = 2 → servidor 2
hash("user:42") % 5 = 3 → servidor 3 (mudou)
Fração de chaves que muda de servidor: ~80%
O que isso significa em produção: 80% das leituras viram falha de cache
de uma vez. O banco atrás recebe, em segundos, o tráfego que o cache
absorvia — e cai. A operação "adicionar capacidade" derruba o sistema.Por que isto é a pergunta clássica
Ela expõe se o candidato pensou em operação. Um cache que não pode crescer sem derrubar o banco é um cache que ninguém consegue operar — e a falha aparece exatamente no momento em que você mais precisa dele, que é sob carga.
Anel de hash: mover o mínimo possível
A ideia é parar de mapear chave para servidor e passar a mapear ambos para o mesmo espaço circular. A chave pertence ao primeiro servidor encontrado andando no sentido horário. Quando um servidor entra, ele assume apenas o trecho entre ele e o anterior — e só as chaves daquele trecho se movem.
A parte que quase sempre falta na resposta
Sem réplicas virtuais, a distribuição fica irregular: com poucos servidores, um pode ficar com um arco muito maior que os outros. A solução é registrar cada servidor em dezenas ou centenas de pontos do anel. Quem menciona isso mostra que já operou, e não só leu.
Os três padrões de uso, e quem é responsável pelo quê
| Padrão | Quem escreve no cache | Quando cabe | O risco |
|---|---|---|---|
| Cache ao lado | A aplicação: procura no cache, e em falha busca no banco e grava | O mais comum. Funciona com qualquer banco e falha de cache não derruba escrita | Duas fontes de verdade no código da aplicação — e é fácil esquecer de invalidar em algum caminho de escrita |
| Cache através | O próprio cache, que fala com o banco | Quando se quer a lógica num lugar só | O cache vira dependência do caminho de escrita: se ele cair, a escrita para |
| Escrita atrasada | O cache, gravando no banco depois | Escrita muito intensa que tolera perda em falha | Perda de dado se o cache morrer antes de descarregar. Aceitável para contador, inaceitável para transação |
A resposta padrão, e por que ela é padrão
Cache ao lado com expiração é o ponto de partida em quase todo sistema: a falha do cache degrada desempenho, não a correção. Os outros dois trocam essa propriedade por algo específico, e a troca precisa ser justificada.
Qual problema o particionamento consistente resolve?
Chave quente e a avalanche
Dois modos de falha que aparecem só em escala, e que o entrevistador costuma perguntar justamente por isso.
- Chave quente: um item — o post do momento, o produto em promoção — recebe tráfego desproporcional. O anel distribui chaves, não carga por chave, então um nó satura enquanto os outros ficam ociosos. Trata-se replicando a chave em vários nós, ou com um cache local de vida curta na aplicação.
- Avalanche: a chave quente expira e mil requisições simultâneas encontram a falha ao mesmo tempo — todas vão ao banco pela mesma informação. Trata-se com uma trava: o primeiro busca e os demais esperam pelo resultado dele.
- Expiração em massa: itens carregados juntos expiram juntos. Adicionar variação aleatória ao tempo de vida espalha a renovação e evita o pico.
- Falha em cascata: se o cache cai por inteiro, o banco recebe cem por cento do tráfego de uma vez. Vale medir se o banco sobrevive a isso — a resposta costuma ser não, e aí o cache virou parte da disponibilidade, não da velocidade.
A pergunta de acompanhamento que revela profundidade
"Seu banco aguenta se o cache cair inteiro?" Se a resposta é não, o cache deixou de ser otimização e virou componente crítico — e precisa de réplica, do mesmo modo que o banco.
Perguntas frequentes
❓ Para que serve hash consistente?
❓ Como lidar com chave quente?
❓ O que acontece quando o cache cai?
Fixando
O que caracteriza a estratégia de escrita através do cache?
Qual é o risco de expirar muitas entradas ao mesmo tempo?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…