Reconciliação interna entre estados derivados sem cron cego

O problema

Backend cresce e começa a carregar estados derivados para ganhar velocidade:

• contadores
• projeções
• índices secundários
• flags de status
• snapshots para leitura

Isso é normal.

O problema aparece quando o derivado descola do estado fonte.

E isso acontece por motivos bem normais:

• falha parcial
• atraso de processamento
• evento perdido
• bug de atualização

A reação mais comum é criar um cron que recalcula tudo.

Às vezes resolve.

Muitas vezes só esconde a falta de desenho.

Modelo mental

Reconciliação interna serve para responder:

• o que pode ficar divergente?
• como detectar a divergência?
• como corrigir sem espalhar dano novo?

Essa conversa é diferente de “rodar um script de tempos em tempos”.

Cron é mecanismo.

Reconciliação é estratégia.

Exemplo simples

Imagine um sistema que guarda:

• pedidos como fonte de verdade
• tabela derivada com order_summary
• contador agregado para dashboard

Se um fluxo atualizar pedido, mas falhar antes de atualizar resumo e contador, o sistema fica parcialmente divergente.

Agora você tem três opções comuns:

• ignorar até alguém reclamar
• recalcular tudo toda noite
• identificar o subconjunto afetado e reparar com critério

A terceira costuma escalar melhor.

O erro comum

O erro comum é achar que cron periódico já é reconciliação.

Mas cron cego costuma ter problemas previsíveis:

• revarre coisa boa demais
• custa caro sem precisão
• não explica a causa da divergência
• pode corrigir e esconder bug estrutural

Você corrigiu o sintoma.

Não melhorou o sistema.

O que normalmente ajuda

Reconciliação melhor costuma combinar:

• detecção de drift
• escopo mínimo de reparo
• capacidade de reconstrução
• trilha de auditoria básica

Exemplos:

• recalcular só IDs marcados como suspeitos
• comparar versão ou checksum
• registrar evento de correção
• permitir rebuild por partição, cliente ou período

Isso deixa a recuperação menos teatral e mais operável.

Onde essa conversa encosta em arquitetura

Se o sistema depende fortemente de estado derivado, ele precisa responder antes:

• qual é a fonte de verdade?
• o derivado pode atrasar?
• o derivado pode ser reconstruído?
• quem observa que ele saiu de sincronia?

Sem isso, toda correção vira improviso operacional.

Como um senior pensa

Quem já viu esse tipo de drift em produção costuma perguntar:

• o derivado é cache, projeção ou estado operacional crítico?
• a divergência é aceitável por quanto tempo?
• como detecto drift sem varrer o planeta?
• como corrijo sem repetir a causa do problema?

Essa camada de julgamento separa “temos um cron” de “temos uma estratégia”.

Ângulo de entrevista

Esse tema aparece em backend, analytics, read models, pipelines e system design.

O entrevistador quer ver se você entende:

• que estado derivado inevitavelmente pode divergir
• que reconciliação não é só agendar script
• que o sistema precisa de fonte clara, detecção e reparo seguro

Resposta forte costuma soar assim:

“Eu trataria reconciliação como parte do desenho do estado derivado. Definiria fonte de verdade, mecanismo de detecção de drift e forma de reparar só o subconjunto afetado. Cron pode ser um veículo, mas não substitui estratégia.”

Takeaway direto

Estado derivado saudável não é o que nunca diverge.

É o que sabe detectar e corrigir a divergência sem se sabotar no processo.