System Design/02 - Componentes/Caching2 min
Write-through
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
A escrita vai para o cache e para o banco de forma síncrona, na mesma operação. O cache está sempre atualizado.
escrever(chave, valor):
cache.set(chave, valor)
banco.set(chave, valor) # síncrono, na mesma transação lógica
# só retorna quando os dois confirmaram
Costuma ser combinado com Cache-Aside na leitura: write-through mantém fresco o que já está lá, e o cache-aside popula o que ainda não foi escrito nesta execução.
Trade-offs
| Ganha | Perde |
|---|---|
| Cache nunca desatualizado | Escrita mais lenta (duas operações) |
| Leitura após escrita sempre acerta | Cacheia dado que ninguém vai ler |
| Sem invalidação para gerenciar | Desperdiça memória |
O problema central é que a maior parte do que se escreve nunca é lido de volta — pelo menos não antes de expirar. Write-through paga memória e latência de escrita por todos os registros, para beneficiar apenas a fração que será relida.
Por isso ele quase sempre aparece com TTL: sem expiração, o cache acumula tudo que já passou pelo sistema.
Há também a questão da atomicidade: escrever em dois sistemas sem transação distribuída significa que uma das duas pode falhar. Se o cache grava e o banco falha, o cache passa a servir um dado que não existe — pior que dado velho. A ordem defensiva é gravar no banco primeiro e no cache depois; se o cache falhar, o pior caso é um miss.
Comparado a Write-behind: write-through é durável e lento; write-behind é rápido e arrisca perder escritas.
Exemplo prático
Sessão de usuário. É escrita e lida a cada requisição, tem tamanho pequeno e previsível, e a razão escrita:leitura é próxima de 1:1.
Write-through é a escolha certa exatamente porque as premissas se invertem: tudo que se escreve será lido, quase imediatamente. Não há desperdício de memória, e a leitura após escrita nunca erra — o usuário nunca vê a sessão anterior.
Contraste com um log de auditoria: escrito constantemente, lido raramente. Write-through ali encheria o cache de registros que ninguém consulta. O padrão correto seria escrever direto no banco, sem cache nenhum.
Relacionado
Parte de Caching · roadmap.sh/system-design