Versionamento de payload interno sem compatibilidade acidental

O problema

Payload interno muda o tempo todo.

Entra:

• novo campo
• campo renomeado
• regra nova
• enum expandido

O erro comum é contar a mesma história:

“acho que vai continuar funcionando”

Às vezes continua.

Mas por acidente.

E compatibilidade acidental é um dos tipos mais chatos de dívida operacional.

Modelo mental

Payload interno não deixa de ser contrato só porque vive dentro do sistema.

Ele ainda separa:

• quem produz
• quem consome
• quem muda primeiro
• quem quebra por último

Então a pergunta útil é:

• essa compatibilidade foi desenhada ou só tolerada?

Se foi só tolerada, você está operando na sorte.

Exemplo simples

Imagine um job antigo que enviava:

• tenant_id
• order_id
• priority

Agora o time quer trocar priority por:

• processing_policy

Se o produtor muda e o consumidor “aceita qualquer coisa” sem semântica clara, parece flexível.

Depois ninguém sabe:

• se o campo velho ainda precisa existir
• qual tem precedência
• quando pode limpar

O payload continua rodando.

Mas virou contrato nebuloso.

O erro comum

O erro comum é chamar isso de backward compatibility só porque o parser não quebrou.

Compatibilidade de verdade precisa dizer:

• o que ainda é aceito
• o que já é obrigatório
• até quando a transição dura
• como validar a migração

Outro erro comum é usar campo opcional como solução para tudo.

Campo opcional demais costuma ser fronteira mal resolvida.

O que normalmente ajuda

Normalmente ajuda tratar a mudança como migração de contrato:

• introduz o novo
• mantém convivência temporária
• observa uso
• remove o velho com critério

Na prática, isso pode aparecer como:

• versão explícita
• shape novo paralelo ao velho
• adaptador de transição
• validação mais rígida depois da convivência

Não precisa criar sistema de versionamento barroco.

Precisa só parar de depender de coincidência.

Como um senior pensa

Quem já teve quebra por ordem de deploy costuma perguntar:

• qual consumidor ainda depende do formato antigo?
• estou desenhando transição ou apostando que tudo sobe junto?
• se um payload velho reaparecer em replay, o sistema entende o que fazer?
• a remoção do formato antigo tem critério ou só esperança?

Essa conversa reduz bastante fragilidade escondida.

Ângulo de entrevista

Esse tema aparece em eventos internos, jobs, contratos entre módulos e evolução de sistema.

O entrevistador quer ver se você entende:

• que payload interno também precisa de compatibilidade bem pensada
• que tolerância vaga não é o mesmo que versionamento
• que replay e deploy fora de ordem expõem contrato ruim

Resposta forte costuma soar assim:

“Eu trataria payload interno como contrato de verdade. Se precisar mudar formato, faria uma transição explícita entre velho e novo, com convivência controlada e limpeza posterior. Não confiaria em compatibilidade acidental nem em deploy perfeitamente sincronizado.”

Takeaway direto

Payload interno que “ainda funciona” não está necessariamente saudável.

Às vezes ele só está quebrando devagar.