A cópia que ninguém testou não é backup

Toda vez que um time troca a base de alguma coisa, aparece a mesma proposta. Pode ser um banco novo, um provedor novo, um serviço reescrito. O formato da frase é sempre parecido:

"Vamos manter os dois por um tempo, só por garantia."

Ninguém discorda. Soa responsável, soa maduro, soa como a decisão que um adulto tomaria. E na maior parte das vezes é a decisão errada.

Não porque redundância seja ruim. Redundância deliberada, testada e com regra clara de quem manda é uma das melhores ferramentas da engenharia. O problema é outro: quase nunca é disso que estamos falando quando dizemos "só por garantia". Estamos falando de manter o sistema antigo ligado porque ninguém confia o suficiente no novo, sem dizer isso em voz alta.

Isso não é redundância. É indecisão com nome bonito.

O que "só por garantia" está realmente dizendo

Vale traduzir a frase antes de discutir os custos, porque a tradução já resolve metade da conversa.

Quando alguém propõe manter as duas pontas vivas, o que está sendo dito é: eu não tenho evidência suficiente de que o caminho novo funciona. Essa é uma informação valiosíssima e completamente legítima. O erro não é sentir isso. O erro é responder a isso com infraestrutura em vez de responder com teste.

Falta de confiança é um problema de conhecimento. Você resolve com experimento. Manter a versão antiga rodando não gera conhecimento nenhum, só adia a pergunta e cobra aluguel enquanto isso.

Três custos que ninguém coloca no orçamento

1. Duas fontes, nenhuma verdade

No momento em que existem duas cópias vivas do mesmo dado, alguém vai ter que decidir qual delas manda. Se essa decisão não estiver escrita, versionada e óbvia pra quem chegar depois, ela vai ser tomada por acaso.

E vai ser tomada da pior forma possível: seis meses depois, às onze da noite, por alguém que não estava na sala quando a migração foi planejada, olhando dois valores diferentes e escolhendo o que parece mais razoável.

O custo aqui não é armazenamento. É a classe inteira de bug que passa a existir. Dados que divergem em silêncio não disparam alerta, não quebram build e não aparecem em teste. Aparecem num relatório, meses depois, quando alguém pergunta por que dois números que deveriam bater não batem.

2. "Por um tempo" nunca tem data

Repare que a proposta original nunca vem com prazo. Não é "vamos manter os dois até dia 30". É "por um tempo".

Sem data, a decisão de desligar precisa ser tomada ativamente por alguém, algum dia, sem nenhum evento forçando. Isso quase nunca acontece. O que era transição vira estado permanente por inércia, e o custo some porque foi diluído em várias contas pequenas que ninguém questiona sozinhas.

Existe um teste rápido pra isso. Pergunte quem vai desligar, e em que data. Se a resposta for silêncio ou "depois a gente vê", você não está fazendo uma transição. Está fazendo uma adição permanente ao sistema, e deveria orçar como tal.

3. A rede de segurança bloqueia o aprendizado

Esse é o custo mais caro e o menos visível.

Enquanto o caminho antigo está ligado, ninguém exercita o novo de verdade. O tráfego se divide, os casos raros continuam caindo no lado conhecido, e a equipe nunca descobre onde o caminho novo quebra. Pior: quando alguma coisa dá errado, a reação natural é voltar pro lado antigo em vez de investigar. É mais rápido, resolve o incidente, e adia o aprendizado outra vez.

Você montou uma rede de segurança que impede exatamente a queda que te ensinaria a andar.

Sistemas ganham confiabilidade sendo usados sob pressão e corrigidos. Um caminho que nunca carrega a carga real nunca vai ser confiável, não importa quantos meses fique no ar em paralelo. Tempo não substitui exposição.

O critério que eu uso

Reduzi isso a uma pergunta que costuma encerrar a discussão rápido:

Se a resposta é não, ele não está pronto pra produção. Deixar ele em produção com muleta não o torna mais pronto, só espalha a incerteza por dois lugares.

Se a resposta é sim, então a cópia antiga não é seguro. É dívida. E dívida tem que ter data de vencimento.

O que essa pergunta faz de útil é forçar a conversa real. Ela transforma "vamos manter por garantia" em "o que exatamente falta pra confiarmos nisso?". A segunda pergunta tem resposta acionável. A primeira só tem custo.

O caminho do meio que funciona

Existe um meio-termo legítimo, mas ele não é manter os dois em produção. É outra coisa:

• Exercite o caminho novo com dado descartável, no volume real, incluindo os casos feios
• Force os cenários que te dão medo em vez de esperar eles acontecerem
• Meça o que vai te fazer dormir tranquilo, e defina o número antes de olhar o resultado
• Quando a dúvida acabar, vire a chave inteira e desligue o antigo

Repare na diferença. Nos dois casos o sistema antigo continua existindo por um tempo. Mas num deles ele está servindo tráfego de verdade e virou parte da arquitetura, e no outro ele está de saída com data marcada enquanto você compra confiança com experimento.

A pergunta que separa os dois é simples: isso aqui está me ensinando alguma coisa, ou só me deixando adiar a decisão?

Quando manter os dois é a resposta certa

Seria desonesto terminar sem isso, porque existem casos claros em que a redundância não é indecisão.

Manter as duas pontas faz sentido quando a operação é irreversível e o dado não pode ser reconstruído. Apagar é definitivo; se a origem não existe em nenhum outro lugar e não dá pra regerar, cautela é cautela mesmo.

Faz sentido quando existe exigência externa. Retenção regulatória e contrato com cliente não estão sujeitos à sua avaliação de risco.

E faz sentido quando a redundância é o desenho, não a dúvida. Réplica com papel definido, failover testado de propósito, regra explícita de quem é a fonte de verdade. Isso é arquitetura, e a diferença aparece num detalhe: você consegue dizer, sem hesitar, qual das cópias manda e o que acontece quando elas divergem.

Se você não consegue responder isso de cabeça, o que você tem não é redundância. É duas coisas parecidas ligadas ao mesmo tempo.

---

O resumo que eu levaria pra próxima reunião de migração: backup é uma coisa, indecisão arquitetada é outra. A primeira tem dono, regra e teste. A segunda só tem conta no fim do mês e um bug esperando daqui seis meses.

Quanto tempo o "só por garantia" de vocês durou?

📩 Vamos conversar