System Design/04 - Cloud Design Patterns/Data Management2 min
Materialized View
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Uma visão pré-computada e persistida dos dados, modelada para servir uma consulta específica — em vez de calculá-la a cada leitura.
dados de origem (normalizados, modelados para escrita)
↓ pré-computa
visão materializada (desnormalizada, modelada para a consulta)
Diferente de uma view comum, que é calculada na hora, a visão materializada é armazenada. A leitura vira um acesso simples.
Como manter atualizada
| Estratégia | Frescor | Custo |
|---|---|---|
| Reconstrução periódica | Minutos a horas | Simples, previsível |
| Incremental por evento | Segundos | Complexa, precisa de idempotência |
| Trigger no banco | Imediato | Onera a escrita (Busy Database) |
| Sob demanda com cache | Variável | Primeira leitura paga |
Trade-offs
O ganho é direto e frequentemente de ordem de grandeza: uma agregação sobre milhões de linhas vira a leitura de uma linha.
O custo é o de toda Denormalization — a cópia precisa ser mantida, e ela sempre estará atrasada em relação à origem. A pergunta que decide o desenho é quanto atraso o caso de uso tolera: um painel executivo aceita 15 minutos; um saldo de conta, não.
Há um ponto operacional importante: a visão deve ser descartável. Se ela pode ser reconstruída da origem, um erro na lógica de atualização é corrigido reconstruindo. Se ela virou fonte da verdade para algum campo, um bug de atualização vira perda de dado.
O custo de reconstrução também limita a estratégia: uma visão que leva seis horas para reconstruir não pode ser recriada sob demanda, o que empurra para atualização incremental — e incremental exige idempotência, porque um evento será processado duas vezes.
E o excesso é real: criar uma visão para cada tela produz dezenas de projeções para manter, cada uma com sua janela de inconsistência e seu custo de armazenamento.
Exemplo prático
Um dashboard de vendas com o total por região e por mês.
-- a cada acesso: varre 50 milhões de linhas, ~40 s
SELECT regiao, mes, SUM(total) FROM vendas GROUP BY regiao, mes;
-- visão materializada, atualizada a cada 15 min
SELECT * FROM vendas_por_regiao_mes; -- ~5 msO dashboard passa de inutilizável a instantâneo, e o banco deixa de sofrer uma varredura completa toda vez que alguém abre a página — que era, além de lento, um Noisy Neighbor para o tráfego transacional.
O trade-off aceito está explícito no nome da janela: os números podem estar até 15 minutos atrasados. Para decisão gerencial, é irrelevante. Para conferência de caixa em tempo real, seria o padrão errado.
Relacionado
Parte de Data Management · roadmap.sh/system-design