Versionamento interno de regra sem comportamento escondido por flag

O problema

Regra muda.

Isso é normal.

O problema começa quando a evolução vira algo como:

• um if no use case
• outro no worker
• uma flag no provider
• uma exceção por tenant

Depois de alguns meses, ninguém sabe mais responder com segurança:

• qual regra vale hoje
• para quem ela vale
• onde ela é escolhida

O sistema continua rodando.

Mas para de ficar claro.

Modelo mental

Versionar regra internamente não é sobre criar burocracia.

É sobre tornar explícito:

• qual comportamento existe
• em que condição cada comportamento entra
• quando a versão antiga será removida

Sem isso, o backend entra em modo de convivência eterna.

Exemplo simples

Imagine uma regra de antifraude.

Antes:

• pedido acima de certo valor pede revisão manual

Depois:

• o cálculo muda por categoria
• alguns tenants entram primeiro
• pedidos internacionais seguem uma lógica diferente

Se isso virar só uma coleção de flags e condicionais espalhadas, o fluxo fica ilegível.

Uma abordagem mais saudável costuma deixar claro:

• versão antiga
• versão nova
• mecanismo central de escolha
• critério de rollout

O erro comum

O erro comum é tratar flag como solução completa de versionamento.

Flag ajuda a ligar e desligar.

Ela não resolve sozinha:

• semântica da mudança
• clareza da decisão
• remoção da versão antiga

Outro erro comum é misturar rollout técnico com exceção permanente de negócio.

Aí o sistema acumula “temporários” que nunca saem.

O que normalmente ajuda

Ajuda bastante quando o backend consegue centralizar:

• a escolha da versão da regra
• o registro observável dessa escolha
• a data ou condição de remoção

Em muitos casos, vale tornar explícito algo como:

• RiskPolicyV1
• RiskPolicyV2

e deixar o ponto de seleção bem visível.

Isso costuma ser melhor do que vinte if espalhados com nomes vagos.

Como um senior pensa

Quem tem mais julgamento costuma perguntar:

• essa diferença é rollout temporário ou exceção estrutural?
• a escolha da versão está concentrada?
• consigo debugar qual regra decidiu este caso?
• o plano de desligamento da versão antiga existe ou é só esperança?

Essa conversa evita que o backend vire um museu de comportamento legado.

Ângulo de entrevista

Esse tema aparece em backend, rollout, antifraude, pricing, eligibility e evolução de sistemas.

O entrevistador quer ver se você entende:

• que regra também precisa de estratégia de evolução
• que flag sem fronteira clara vira opacidade
• que rollout bom pede observação e remoção explícita

Resposta forte costuma soar assim:

“Eu evitaria espalhar a nova regra em condicionais locais. Preferiria explicitar as versões e centralizar a escolha por cohort ou condição. Flag ajuda rollout, mas não substitui desenho claro da transição.”

Takeaway direto

Regra evolui melhor quando a versão é explícita.

Quando ela fica escondida, o backend perde previsibilidade.