Como Remover Dependências Antigas Sem Apagar Suporte Cedo Demais

O problema

Quase toda migração chega num ponto em que alguém diz:

“Agora e só limpar o legado.”

E e justamente nessa hora que muita gente se machuca.

Porque “legado” quase nunca e só um arquivo feio ou uma rota esquecida.

Pode ser:

• um fallback usado em incidente
• um consumidor antigo que quase não aparece
• um job operacional que roda uma vez por semana
• um cliente externo que ainda depende do comportamento velho

Remover cedo demais parece limpeza.

Na prática, pode ser amputacao mal planejada.

Modelo mental

Pense assim:

dependência antiga só pode morrer quando deixa de sustentar qualquer caminho relevante, inclusive os que você esqueceu

Isso significa que remoção segura não acontece por sensação.

Ela acontece por evidência.

Você precisa responder:

• quem ainda usa isso
• quem ainda pode precisar disso em rollback
• que fluxo degradado ainda cai nesse caminho
• por quanto tempo faz sentido manter a compatibilidade

Quebrando o problema

Descubra se a dependência esta viva de forma obvia ou silenciosa

Algumas dependências velhas aparecem no tráfego normal.

Outras só aparecem quando algo da errado.

As piores de remover sao essas:

• fallback raramente acionado
• rota de reprocessamento
• script operacional
• consumidor de baixo volume

Se você medir só caminho feliz, vai concluir cedo demais que já pode apagar.

Diferencie suporte temporário de uso estrutural

Nem tudo que ainda existe merece ficar para sempre.

Mas também nem tudo que parece temporário já pode morrer.

Uma pergunta útil e:

isso ainda existe porque ninguém limpou, ou porque a transição ainda depende dele?

A resposta muda tudo.

Cheque dependência de rollback antes de remover

Tem time que olha o tráfego atual, ve que o caminho antigo quase não recebe nada e apaga.

Só que rollback, por definição, não depende do estado normal.

Depende do pior momento.

Se rollback ainda precisa:

• ler formato antigo
• publicar evento antigo
• chamar endpoint legado
• usar tabela antiga como fallback

entao o suporte ainda não morreu.

Desligue em etapas, não em uma lapada só

Remoção segura costuma ser progressiva:

1. parar de expandir a dependência
2. bloquear novos consumidores
3. medir uso restante
4. desligar em ambiente ou cohort controlado
5. só depois apagar de vez

Essa ordem parece lenta.

Mas evita que “limpeza” vire incidente sem caminho de volta.

Deixe claro o critério de fim

Se você não define quando algo pode ser removido, o legado nunca morre.

Se define mal, ele morre cedo demais.

Critério de fim bom costuma incluir:

• ausencia de tráfego por período relevante
• inexistencia de dependência para rollback
• confirmação com consumidores reais
• observabilidade suficiente para detectar regressao depois da remoção

Exemplo simples

Imagine uma API que passou a gerar evento novo em Kafka, mas ainda mantem um webhook antigo para parceiros.

O time ve que quase todo mundo já usa o evento novo e quer apagar o webhook.

Só que:

• um parceiro pequeno ainda depende dele
• o time de suporte usa esse webhook num fluxo de reprocessamento manual
• rollback da integração nova ainda reativa esse caminho

Apagar agora seria precipitado.

Plano melhor:

1. bloquear novos parceiros no webhook antigo
2. medir quem ainda consome
3. migrar o parceiro restante
4. ajustar o processo de suporte
5. garantir rollback sem esse webhook
6. só entao remover

Erros comuns

• Confundir baixo volume com risco baixo.
• Apagar caminho legado sem checar fallback e rollback.
• Medir uso normal, mas ignorar uso eventual em erro ou reprocessamento.
• Não avisar consumidor externo que ainda depende do suporte antigo.
• Deixar o legado eterno porque ninguém definiu dono e critério de remoção.

Como um senior pensa

Quem tem mais experiência desconfia de frases como:

“Acho que ninguém mais usa isso.”

Porque “acho” e uma base muito fraca para apagar estrutura que pode salvar um incidente.

Senioridade aqui aparece em transformar intuição em prova.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você sabe encerrar transição com responsabilidade.

Você sobe de nivel quando:

• fala de consumidores esquecidos
• lembra de fallback e rollback
• propoe desligamento gradual
• define critério objetivo para remoção

Uma resposta forte costuma soar assim:

“Eu não apagaria suporte antigo só porque o uso aparente caiu. Primeiro mediria quem ainda depende dele, validaria rollback sem esse caminho, bloquearia novos usos e desligaria em etapas antes da remoção definitiva.”

O jeito mais perigoso de limpar legado e assumir que o que quase não aparece já não importa.

Dependência antiga deixa de ser problema técnico quando você prova que ela deixou de ser problema operacional.