Feature flag no backend sem espalhar if pelo sistema inteiro

O problema

Feature flag parece inocente no começo.

Você quer:

• liberar aos poucos
• testar comportamento novo
• reduzir risco de rollout

Então adiciona:

• um if no handler

Depois:

• um if no use case
• outro no worker
• outro no consumer
• outro no cron

Quando percebe, a flag já não controla só rollout.

Ela virou uma segunda arquitetura paralela.

Modelo mental

Flag boa decide:

• qual caminho entra
• para quem entra
• até quando existe

Ela não deveria espalhar incerteza pelo sistema inteiro.

Em backend, geralmente a pergunta melhor é:

onde está o ponto de decisão mais alto que já separa bem o fluxo?

Esse costuma ser o melhor lugar para a flag.

Onde a flag costuma ficar melhor

Muitas vezes faz sentido que a escolha fique:

• no ponto de entrada do caso de uso
• numa política central de roteamento
• numa composição que escolhe estratégia A ou B

O que normalmente piora a base:

• mesma flag consultada em cinco camadas
• caminho antigo e novo misturados dentro do mesmo método
• regra de persistência conhecendo flag de rollout

Isso torna o sistema difícil de ler e mais difícil ainda de limpar depois.

Exemplo simples

Imagine uma nova forma de calcular frete.

Uma forma ruim:

• handler checa a flag
• use case checa de novo
• service de preço checa mais uma vez

Uma forma melhor:

• um ponto central escolhe LegacyFreightCalculator ou NewFreightCalculator
• o resto do fluxo continua trabalhando contra uma interface interna estável

O rollout continua existindo.

Mas a contaminação cai muito.

O erro comum

O erro comum é tratar flag como atalho permanente.

O time pensa:

• “depois limpamos”

E nunca limpa.

Aí a base acumula:

• branch morta
• condição impossível de rastrear
• comportamento que ninguém mais sabe qual é o default

Flag madura precisa nascer com:

• dono
• janela de vida
• critério de remoção

Quando flag realmente ajuda

No backend, flag ajuda bastante quando você precisa:

• fazer rollout gradual
• conviver temporariamente com caminho antigo e novo
• reduzir blast radius
• desligar comportamento novo sem rollback completo

Mas flag não substitui:

• desenho de módulo
• estratégia de migração
• limpeza depois da transição

Como um senior pensa

Quem decide melhor costuma perguntar:

• a flag controla um ponto de escolha claro ou está vazando para todo lado?
• isso é rollout temporário ou duas lógicas permanentes disfarçadas?
• onde o sistema deveria decidir o caminho de forma mais estável?
• quem vai remover essa flag e quando?

Essa última pergunta salva muita base de virar museu de rollout antigo.

Ângulo de entrevista

Esse tema aparece em rollout, backend architecture e mitigação de risco.

O entrevistador quer ver se você:

• usa flag com critério
• sabe evitar if espalhado
• pensa em remoção e manutenção

Resposta forte costuma soar assim:

“Eu usaria a flag para escolher o fluxo em um ponto alto e manter o resto do sistema estável. Evitaria checar a mesma flag em várias camadas e já definiria critério de remoção, para não transformar rollout temporário em complexidade permanente.”

Takeaway direto

Feature flag boa controla o risco.

Feature flag ruim espalha indecisão pelo código inteiro.