Versão velha e nova convivendo ao mesmo tempo

O problema

Muita migração começa com uma fantasia silenciosa:

“No momento do deploy, todo mundo passa a usar a versão nova.”

Na prática, não e assim.

Durante a transição, convivem:

• instancias antigas
• instancias novas
• mobile desatualizado
• job antigo rodando
• mensagem velha chegando da fila
• cliente externo que ainda usa o contrato anterior

Se o seu desenho depende de troca instantanea, o problema não e o ambiente.

O problema e o plano.

Modelo mental

Pense assim:

estado misto não e bug de rollout; e estado normal de um sistema em mudança

Quando você aceita isso, a pergunta certa deixa de ser:

“Como eu faco todo mundo mudar junto?”

E vira:

“Como eu faco velho e novo conversarem sem se atrapalhar por tempo suficiente?”

Quebrando o problema

Separe compatibilidade de leitura e de escrita

Essas duas coisas parecem juntas, mas não sao.

Compatibilidade de leitura responde:

• o código novo consegue entender dado velho?
• o consumidor novo consegue lidar com evento antigo?

Compatibilidade de escrita responde:

• o produtor novo gera algo que o consumidor antigo ainda aceita?
• a aplicação nova grava dado que a antiga ainda consegue ler?

Quando o time mistura as duas, costuma quebrar metade sem perceber.

Prefira mudança aditiva antes de mudança destrutiva

Mudança segura costuma se parecer com:

• adicionar campo opcional
• aceitar formato antigo por um tempo
• ler novo quando existir e cair para o velho quando não existir

Já mudança arriscada costuma se parecer com:

• remover campo exigido cedo demais
• trocar formato de uma vez
• assumir que consumidor antigo vai se adaptar sozinho

Compatibilidade boa quase sempre compra tempo.

Deixe produtor e consumidor envelhecerem em ritmos diferentes

Em sistema real, os lados raramente atualizam juntos.

Por isso, uma regra simples ajuda muito:

• consumidor deve ser tolerante quando puder
• produtor deve ser conservador quando a mudança ainda esta em rollout

Isso evita que uma parte mais rápida derrube a parte mais lenta.

Tenha critério para conviver e critério para remover

Conviver sem fim vira lixo acumulado.

Mas remover cedo demais vira incidente.

Você precisa definir:

• quanto tempo a compatibilidade temporária vai existir
• como medir se ainda ha tráfego antigo
• que dependências precisam sair antes da remoção
• qual rollback ainda depende do formato velho

Sem essa disciplina, versão antiga vira fantasma permanente.

Não esconda falta de compatibilidade atras de número de versão

Número de versão ajuda organização.

Não substitui politica de compatibilidade.

Você pode ter:

• API v2 quebrando cliente a cada semana
• evento “versionado” que ainda exige sincronismo perfeito
• payload com número bonito e convivencia pessima

Versão sem regra de convivência e só rótulo.

Exemplo simples

Imagine um evento de pedido pago.

Antes:

{
  "orderId": "o-123",
  "status": "paid"
}

Agora o time quer incluir mais contexto:

{
  "orderId": "o-123",
  "status": "paid",
  "paidAt": "2026-03-23T18:00:00Z",
  "source": "pix"
}

Se o consumidor antigo ignora campos desconhecidos, ele segue vivo.

Se o consumidor novo aceita que paidAt e source ainda podem não existir em mensagens antigas, ele também segue vivo.

Essa convivência e bem mais segura do que trocar o formato inteiro e esperar sincronismo perfeito.

Erros comuns

• Assumir que deploy simultâneo vai acontecer.
• Fazer consumidor novo quebrar quando campo novo ainda não existe.
• Remover contrato antigo sem medir quem ainda depende dele.
• Criar versão nova sem estratégia de depreciação.
• Deixar compatibilidade temporária virar regra eterna porque ninguém definiu fim.

Como um senior pensa

Quem tem mais experiência trata estado misto como parte do projeto, não como detalhe operacional.

A pergunta boa costuma ser:

“Se metade do ecossistema estiver velha e metade nova na proxima hora, o que continua funcionando?”

Se a resposta for “quase nada”, a mudança ainda esta fraca.

O que o entrevistador quer ver

Em entrevista, esse tema mede se você entende sistemas distribuidos fora do modo idealizado.

O avaliador quer ver se você:

• aceita convivencia parcial entre versões
• pensa em compatibilidade de leitura e escrita
• prefere mudança aditiva quando possível
• define critério de remoção, não só de introdução

Uma resposta forte costuma soar assim:

“Eu desenharia a mudança para velho e novo conviverem por um tempo. Isso significa consumidor tolerante, produtor conservador, mudança aditiva primeiro e remoção só depois que eu provar que o caminho antigo parou de ser necessário.”

Sistema em transição não precisa de perfeição. Precisa de compatibilidade suficiente para atravessar a mudança sem quebrar.

O momento mais perigoso não e quando tudo ficou velho. E quando metade ficou nova.