System Design/02 - Componentes/Caching2 min
Write-behind
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Também chamado write-back. A escrita vai só para o cache, que confirma imediatamente; a persistência no banco acontece depois, em background e frequentemente em lote.
escrever(chave, valor):
cache.set(chave, valor)
fila.push(chave) # persiste depois
return OK # já responde
background:
a cada N segundos ou N itens → grava o lote no banco
Trade-offs
| Ganha | Perde |
|---|---|
| Escrita muito rápida (latência do cache) | Risco de perda de dados |
| Absorve picos de escrita | Complexidade real |
| Agrupa escritas — muito menos I/O | Banco fica temporariamente desatualizado |
| Coalescing: N updates viram 1 | Ordem e consistência ficam por sua conta |
O ganho mais subestimado é o coalescing: se um contador é incrementado 1.000 vezes em 10 segundos, o write-behind grava uma vez o valor final. A carga no banco cai por ordem de grandeza, não por percentual.
O custo é igualmente direto: se o cache morre antes do flush, aquelas escritas se foram. Não há transação, não há confirmação do banco — o sistema disse "OK" para o cliente sobre um dado que ainda não existia em lugar durável.
As mitigações reduzem o risco sem eliminá-lo: cache com persistência (AOF do Redis), replicação, flush mais frequente (que reduz o coalescing), e um log durável antes do cache.
Por isso a regra prática: write-behind serve para dado tolerante a perda. Contador de visualizações, última atividade, métrica agregada. Nunca para transação financeira, pedido ou qualquer coisa cuja perda o usuário perceba.
Complicação adicional: leituras precisam vir do cache, senão veem o valor antigo do banco. E se o cache reinicia, ele precisa saber o que ainda não foi persistido.
Exemplo prático
Contador de visualizações de vídeo em plataforma grande. Escrita direta no banco seria inviável — milhões de incrementos por minuto em linhas concentradas produziriam contenção de lock catastrófica.
Com write-behind, o contador vive em Redis (INCR, atômico e rápido) e um job persiste o valor no banco a cada 30 segundos.
Perder 30 segundos de contagem numa queda do Redis é aceitável: ninguém percebe que o vídeo tem 1.847.203 em vez de 1.847.391 visualizações. Esse é exatamente o critério que autoriza o padrão — e que o desautorizaria num saldo de conta.
Relacionado
Parte de Caching · roadmap.sh/system-design