Recomputação incremental sem recalcular o mundo inteiro

O problema

Estado derivado envelhece.

Regra muda.

Evento falha.

Projeção deriva.

Em algum momento aparece a pergunta:

• como recalcular isso?

Muita arquitetura responde com dois extremos:

• não mexe
• recalcula tudo

O primeiro deixa drift acumular.

O segundo transforma manutenção em pancada global.

Modelo mental

Recomputação incremental parte de uma pergunta simples:

• o que realmente mudou?

Se a resposta arquitetural for sempre “o sistema inteiro”, provavelmente o recorte está ruim.

Na prática, estado derivado quase sempre pode ser particionado por:

• chave
• tenant
• janela de tempo
• agregação específica
• dependência local

É daí que nasce recomputação mais barata.

Exemplo simples

Imagine um relatório diário por conta.

Se uma correção afetou uma transação de terça-feira de uma conta específica, faz mais sentido recomputar:

• aquela conta
• naquele intervalo

do que refazer o histórico inteiro de todas as contas.

Se a arquitetura não permite esse recorte, o custo de correção vira desproporcional.

O erro comum

O erro comum é tratar recomputação total como fallback permanente.

Às vezes ela é necessária.

Mas quando vira rotina para qualquer ajuste, ela:

• compete com tráfego normal
• encarece operação
• aumenta janela de repair
• esconde granularidade mal desenhada

Outro erro comum é chamar de incremental algo que só é “menos total que ontem”, mas ainda recalcula demais.

O que normalmente ajuda

Normalmente ajuda modelar desde cedo:

• unidade de recomputação
• dependência mínima
• forma de recorte operacional
• observabilidade do que foi recalculado

Na prática, isso costuma aparecer como:

• reprocessar por chave
• recomputar por bucket temporal
• rebuild por partição
• refazer só o agregado tocado

Não exige perfeição.

Exige só que a arquitetura saiba corrigir local sem sempre explodir para global.

Como um senior pensa

Quem já sofreu com recalculo total recorrente costuma perguntar:

• qual é a menor unidade segura de recomputação?
• consigo provar que esse recorte basta?
• o custo de recalcular tudo virou muleta para modelagem ruim?
• esse repair ainda cabe na operação normal?

Essa conversa evita muito job gigante que existe porque ninguém conseguiu desenhar escopo menor.

Ângulo de entrevista

Esse tema aparece em read models, analytics, billing, eventos e estado derivado.

O entrevistador quer ver se você entende:

• que recomputação também é decisão de arquitetura
• que granularidade de repair importa
• que recalcular tudo para qualquer mudança denuncia acoplamento ou particionamento ruins

Resposta forte costuma soar assim:

“Eu tentaria desenhar a recomputação por chave, janela ou partição, para corrigir o necessário sem sempre refazer o universo inteiro. Recalculo total eu deixaria como exceção controlada, não como modo normal de correção.”

Takeaway direto

Se qualquer ajuste exige recalcular o mundo inteiro, o problema não é só operacional.

É arquitetural também.