Shadow Traffic, Dual Write e Comparação de Comportamento

O problema

Quando um fluxo novo nasce ao lado do legado, o time logo quer uma resposta:

“Como eu ganho confiança antes de mandar todo mundo para o novo?”

E ai aparecem várias técnicas com nomes que soam fortes:

• shadow traffic
• dual write
• comparação de comportamento

O problema e que muita gente usa essas palavras como se fossem sinonimos de segurança.

Não sao.

Elas só ajudam quando você sabe:

• o que quer validar
• o que ainda não consegue provar
• qual risco novo você esta introduzindo ao tentar reduzir o risco antigo

Modelo mental

Pense assim:

essas técnicas sao jeitos de observar o novo antes de confiar totalmente nele

Mas cada uma observa um angulo diferente.

• shadow traffic ajuda a ver como o novo reagiria ao tráfego real sem virar caminho oficial
• dual write ajuda a manter dois destinos atualizados ao mesmo tempo
• comparação de comportamento ajuda a detectar divergencia entre velho e novo

Se o time mistura tudo, a estratégia fica cara e confusa.

Quebrando o problema

Shadow traffic serve para exercitar o novo com tráfego real

Aqui a ideia e espelhar requisição ou evento para o caminho novo sem deixar que ele responda oficialmente ao usuário.

Isso ajuda a responder:

• o novo aguenta o volume?
• a latência faz sentido?
• ele quebra com dados reais que não apareciam no staging?

Mas shadow traffic não valida tudo.

Se o fluxo depende de side effect real, só espelhar tráfego pode não bastar.

Dual write serve para manter dois mundos atualizados durante a transição

No dual write, o sistema escreve em dois lugares:

• legado
• novo

Isso parece uma ponte poderosa.

Também abre risco novo:

• uma escrita passa e a outra falha
• a ordem diverge
• reconciliação fica chata
• time assume consistência que não existe

Dual write precisa de plano de erro.

Não só de código duplicado.

Comparação de comportamento precisa de critério, não só diff cego

Se você compara resposta de velho e novo, precisa saber o que significa divergencia relevante.

Exemplos:

• campo extra não necessariamente e problema
• ordem diferente pode ser irrelevante
• arredondamento diferente pode ser gravissimo em cobrança

Sem regra clara, a comparação vira ruido.

Não tente validar tudo com uma técnica só

As vezes shadow traffic ajuda a validar robustez.

As vezes comparação de resultado basta.

As vezes dual write e necessário por causa de persistencia.

A pergunta certa não e:

“Qual técnica e mais avancada?”

E sim:

“Qual incerteza eu preciso reduzir antes do corte?”

Toda técnica de confiança também cria custo operacional

Esse ponto muita gente ignora.

Quando você adiciona:

• espelhamento de tráfego
• escrita duplicada
• reconciliação
• diff entre saídas

você também adiciona:

• mais observabilidade
• mais storage
• mais lógica de falha
• mais coisa para desligar depois

Ferramenta de transição que nunca sai vira novo legado.

Exemplo simples

Imagine um motor novo de calculo de frete.

O time não quer trocar tudo de uma vez.

Uma estratégia razoavel pode ser:

1. shadow traffic para ver como o novo responde aos pedidos reais
2. comparação entre valor calculado pelo velho e pelo novo
3. definição clara do que e divergencia aceitavel ou não
4. rollout para poucos usuários quando o comportamento estiver estavel

Se o novo também precisa gravar em storage próprio durante a migração, talvez entre dual write.

Mas ai o time precisa combinar:

• o que faz se uma escrita falhar
• qual lado e fonte de verdade temporária
• como reconciliar diferencas

Erros comuns

• Achar que shadow traffic substitui validação funcional completa.
• Fazer dual write sem plano de reconciliação.
• Comparar respostas sem definir critério de divergencia relevante.
• Adicionar técnicas demais e perder clareza do objetivo.
• Esquecer de remover a instrumentacao de transição depois que ela cumpriu o papel.

Como um senior pensa

Quem tem mais experiência não usa essas técnicas para parecer sofisticado.

Usa para responder perguntas concretas, como:

“Eu preciso validar capacidade, corretude, persistencia ou impacto real no usuário?”

Essa pergunta evita muito excesso.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você sabe reduzir risco sem criar ilusão de certeza.

Você sobe de nivel quando:

• diferencia shadow traffic, dual write e comparação de comportamento
• aponta o risco adicional de cada técnica
• escolhe ferramenta pelo tipo de incerteza
• lembra de reconciliação e desligamento da estratégia de transição

Uma resposta forte costuma soar assim:

“Eu usaria shadow traffic para exercitar o novo com tráfego real, compararia comportamento para detectar divergencia relevante e só usaria dual write quando realmente precisasse manter dois destinos vivos, porque ele também introduz inconsistência e custo operacional.”

Técnica de migração boa não elimina risco. Ela transforma risco invisível em sinal observável.

Se a estratégia de validação ficou mais perigosa do que a mudança, ela foi mal escolhida.