Escrita dupla interna com verificação

O problema

Em algum momento o backend precisa escrever em dois lugares.

Por exemplo:

• módulo antigo e módulo novo
• storage legado e storage novo
• estado transacional e projeção interna nova

O time costuma chamar isso de transição controlada.

Até aí, tudo bem.

O problema começa quando “gravou nos dois” vira sinônimo de “está consistente”.

Não está.

Está só mais exposto a divergência invisível.

Modelo mental

Escrita dupla interna é uma técnica de migração e comparação.

Ela existe para responder:

• o sistema novo está acompanhando o comportamento do antigo?

Para isso funcionar, você precisa de quatro coisas:

• fonte de verdade explícita
• regra de sucesso e falha
• verificação de paridade
• repair para divergência

Sem essas quatro peças, dual write vira superstição operacional.

Exemplo simples

Imagine uma migração do módulo de pedidos.

Durante um período, cada criação de pedido grava:

• no modelo legado
• no modelo novo

Se ambas responderem 200, muita gente relaxa.

Mas isso ainda não prova que:

• serialização foi igual
• regra aplicada foi igual
• leitura futura vai bater

É por isso que a fase útil de dual write sempre precisa de verificação posterior:

• comparação por chave
• checksum
• diff de leitura
• amostra de paridade

O erro comum

O erro comum é tratar a confirmação dos dois writes como garantia suficiente.

Outro erro comum é não escolher quem manda quando há divergência.

Sem fonte autoritativa, qualquer mismatch vira impasse:

• qual lado está certo?
• quem repara?
• o que pode ser descartado?

Também é comum deixar dual write viver para sempre.

A técnica nasceu para atravessar uma ponte.

Se vira estado permanente, o time provavelmente não terminou a decisão arquitetural.

O que normalmente ajuda

Normalmente ajuda definir desde o começo:

• quem é source of truth durante a transição
• qual chave correlaciona as duas escritas
• como medir paridade
• quanto drift é aceitável
• quando o cutover está liberado

Na prática, isso costuma vir com:

• escrita idempotente
• comparação assíncrona
• fila de divergência
• repair seletivo
• janela operacional clara

Sem isso, dual write parece sofisticado, mas só multiplica ponto de falha.

Como um senior pensa

Quem já fez migração séria costuma perguntar:

• qual escrita é mandatória e qual é comparativa?
• se uma falhar, eu aborto tudo ou sigo e reparo depois?
• consigo provar que a leitura do sistema novo bate com a antiga?
• qual é o critério objetivo para desligar a escrita antiga?

Essa conversa separa rollout controlado de “estamos escrevendo em dois lugares e torcendo”.

Ângulo de entrevista

Esse tema aparece em migração, cutover, read model, storage e modernização de backend.

O entrevistador quer ver se você entende:

• que dual write não é consistência forte por mágica
• que comparação e repair fazem parte do desenho
• que arquitetura de transição precisa de fim claro

Resposta forte costuma soar assim:

“Eu usaria escrita dupla como etapa de migração, com uma fonte autoritativa definida e uma camada de verificação de paridade. Sem isso, a gente só escreve em dois lugares e ganha dois motivos para divergir.”

Takeaway direto

Escrita dupla sem verificação não é segurança extra.

É só risco duplicado com nome bonito.