O que é feature flag? Um guia de SRE, com código e exemplos

São 03:12 e a taxa de erro do checkout acabou de passar de 4%. A mudança que causou o problema foi publicada seis horas atrás. Ninguém quer reverter a release inteira, porque ela também traz duas correções sem relação com o incidente. Então, o que é feature flag nessa situação? É um condicional no seu código, lido em tempo de execução, que decide se um caminho de código roda. Você desliga a flag e o caminho novo deixa de executar, sem novo build e sem novo deploy. A ideia inteira cabe nisso. O resto é operação.

O que é feature flag de fato, e o que ela não é

Uma feature flag é um ponto de decisão. Em algum lugar do código existe um if, e o valor que ele lê vem de fora do binário: um serviço de configuração, uma linha de banco de dados, o SDK de um fornecedor ou uma variável de ambiente que você muda sem reiniciar.

const useNewPricing = await flags.isEnabled("new-pricing-engine", {
  userId: user.id,
  plan: user.plan,
  region: request.region,
});

return useNewPricing
  ? newPricingEngine.quote(cart)
  : legacyPricing.quote(cart);

Três coisas decorrem desse trecho. O caminho antigo ainda precisa existir e precisa funcionar. A flag precisa de contexto (quem está pedindo) se você quer algo mais inteligente do que ligado ou desligado. E a avaliação fica no caminho quente de cada requisição, então a latência e o modo de falha dela agora são problema seu.

Muita gente usa "feature toggle" e "feature flag" como sinônimos. O nome não importa. O comportamento importa: você separa o deploy do código da liberação da funcionalidade. O código vai para produção escondido, e uma pessoa ou um sistema decide depois quem vai ver.

Os quatro tipos de flag, e por que misturá-los dói

Grande parte da dor com flags vem de tratar todas como se fossem uma coisa só. A taxonomia de feature toggles de Martin Fowler separa as flags pelo tempo de vida e pelo grau de dinamismo da decisão. Na prática, ela se sustenta.

Release toggles são transitórias. Escondem trabalho inacabado atrás de uma flag para você fazer merge na trunk todo dia. A orientação de Fowler é que elas raramente sobrevivam a uma ou duas semanas. A decisão é estática: toda requisição de uma mesma release recebe a mesma resposta.

Experiment toggles direcionam usuários diferentes para variantes diferentes. Ficam no ar pelo tempo necessário para atingir significância estatística, de horas a semanas, e não mais que isso. A decisão é tomada por requisição.

Ops toggles controlam o comportamento operacional: desligar uma funcionalidade não crítica sob carga, trocar para uma dependência de contingência, desativar uma consulta cara. Algumas viram kill switches de longa duração. Elas precisam mudar em segundos, o que descarta qualquer coisa que exija um novo release.

Permission toggles liberam funcionalidades por plano ou direito de acesso. Podem existir por anos, e a decisão é tomada por usuário em cada requisição.

O erro é dar aos quatro o mesmo ciclo de vida. Uma permission toggle precisa de dono e de trilha de auditoria para sempre. Uma release toggle precisa de uma data de remoção no dia em que é criada. Se você não consegue dizer que tipo de flag é olhando para o nome, também não consegue dizer quais são seguras para remover.

Por que SREs se importam: flags como controle de blast radius

Para um time de plataforma, a propriedade interessante não é o teste A/B. É que a flag transforma um release em um evento controlável, como um dial.

Sem flags, um deploy expõe 100% do tráfego à mudança de uma vez. A única reversão é outro deploy, e ela leva o tempo do seu pipeline mais o tempo que um humano leva para ter certeza. Com flags, você expõe 1% dos usuários, observa a taxa de erro e o p99, e então sobe para 5, 25, 50. O blast radius é o percentual que você escolheu, e a reversão é uma mudança de configuração que se propaga em segundos.

Isso muda o seu tempo médio de recuperação mais do que a maior parte dos investimentos em ferramentas. A pergunta do post-mortem deixa de ser "por que levamos 40 minutos para reverter" e passa a ser "por que isso não estava atrás de uma flag".

O dial tem um porém. Alguém precisa acompanhar os sinais e girar o dial. Às 03:12, essa pessoa está cansada. A versão útil de um sistema de flags amarra o dial a um SLO: se a taxa de erro consumir uma fatia definida do error budget, o rollout para e reverte sem humano no meio. A maioria dos times constrói isso na mão, com um webhook que vai do alerta para a API de flags. São algumas centenas de linhas, e a conta se paga na primeira noite em que disparar.

A conta chega: dívida de flags e a lição da Knight Capital

Cada flag que você adiciona, em teoria, dobra o número de caminhos pelo código. Na prática, você testa algumas combinações e torce para o resto funcionar. Fowler recomenda tratar flags como inventário com custo de manutenção: crie uma tarefa de remoção no backlog no momento em que a flag nasce, coloque datas de expiração e, nos times mais rigorosos, faça o build falhar quando uma flag expirada ainda estiver no código.

A versão cara dessa lição é a Knight Capital. Em 1º de agosto de 2012, um novo deploy reutilizou uma flag antiga, que um dia controlou uma funcionalidade aposentada. Um servidor não recebeu o deploy e continuou rodando o código antigo. Nos primeiros 45 minutos após a abertura do pregão, o roteador da empresa enviou mais de 4 milhões de ordens ao mercado tentando executar 212 ordens de clientes, como registra a ordem da SEC contra a Knight Capital. O artigo de Fowler cita a perda de cerca de $460 milhões como alerta sobre flags que ninguém gerencia.

A flag não foi a única falha ali. Deploy manual, ausência de kill switch e detecção lenta também pesaram. Mas a reutilização do nome de uma flag morta é o detalhe que todo time de plataforma deveria ter pregado na parede. Nunca reaproveite uma flag. Apague a antiga, crie uma nova e trate a remoção como uma etapa de primeira classe.

Construir ou comprar uma plataforma de flags?

Um sistema caseiro começa como um arquivo de configuração e um booleano. Isso serve para as primeiras dezenas de release toggles em um serviço. Deixa de servir quando você precisa de rollouts percentuais que se mantenham fixos por usuário, regras de direcionamento por segmento, um log de auditoria de quem mudou o quê e uma mudança de flag que chega a todas as instâncias em segundos, sem uma avalanche sobre o seu armazenamento de configuração.

Nesse ponto, você está comparando plataformas por critérios mensuráveis: latência de avaliação do SDK (avaliação local ou chamada de rede), streaming ou polling para as atualizações, granularidade das regras de direcionamento, suporte a múltiplos ambientes e como o medidor de preço escala com o seu tráfego.

Os medidores diferem mais do que as listas de funcionalidades.

O LaunchDarkly é a implementação de referência da categoria: direcionamento maduro, releases protegidas e uma superfície de integração profunda. Os planos por uso cobram por conexão de serviço e por mil usuários ativos mensais do lado do cliente, então um app de consumo com um público anônimo grande pode ver a conta oscilar de formas que uma equipe só de backend não vê. O caso a favor é real: se você precisa de governança e auditoria em escala empresarial, ele teve mais tempo para amadurecer essa parte.

O Statsig reúne flags, experimentação e análise de produto, e cobra por evento. Isso combina com times que tratam flags principalmente como superfície de experimentos. Se o seu caso são sobretudo ops toggles e kill switches, você paga por uma análise que talvez nunca leia. Vale notar também que o fornecedor trocou de dono duas vezes desde setembro de 2025, o que merece uma linha na sua revisão de risco de fornecedores.

Qualquer que seja a escolha, teste o modo de falha antes de assinar. Bloqueie o acesso de rede do SDK em staging e veja o que a aplicação faz. Um SDK bom serve os últimos valores de flag conhecidos a partir do cache e registra o problema de forma clara. Um SDK ruim trava o caminho da requisição.

A observabilidade é metade do sistema de flags

Uma flag sem telemetria é um palpite. O mínimo útil é anexar o estado da flag a cada trace e a cada linha de log da requisição, para que, quando surgir um pico de erros, você agrupe por variante e veja se o caminho novo é a causa.

O Datadog e plataformas all-in-one parecidas tornam fácil o detalhamento por variante, desde que o seu SDK marque os spans. O porém é que a cobrança por host e por sinal cresce rápido quando você adiciona tags de alta cardinalidade, como a combinação de chave da flag, variante e segmento de usuário. Seja deliberado sobre quais dimensões você marca.

O Grafana é o caminho mais barato se você já roda Prometheus e OpenTelemetry. Você vai construir os dashboards com visão de flags por conta própria, o que custa tempo de engenharia, mas dá controle total sobre os labels que emite. Para um time de 50 a 500 engenheiros com um grupo de plataforma, essa troca costuma ser a certa.

Um runbook curto para a sua primeira flag em produção

Se você está introduzindo flags em um time que não tem nenhuma, mantenha o primeiro rollout entediante.

1. Escolha uma mudança com métrica de sucesso clara, como a taxa de erro do checkout ou o p99 de um endpoint.

2. Nomeie a flag com o tipo e o dono, por exemplo release.checkout.new-tax-calc.owner-payments.

3. Crie a tarefa de remoção agora e coloque uma data de expiração de no máximo duas semanas.

4. Libere para 1% e segure por um ciclo completo de tráfego, depois suba. Defina antecipadamente o limiar em que você reverte.

5. Torne a reversão um único comando ou botão, e ensaie uma vez em staging antes de precisar dele à noite.

6. Depois que 100% estiver estável por alguns dias, apague a flag e o caminho antigo de código na mesma mudança.

A parte sem glamour é o passo 6. Times que pulam esse passo acabam com algumas centenas de flags, sem ninguém que saiba o que metade delas faz, e com um risco com cara de Knight Capital guardado no repositório.

Como teria sido o seu último incidente atrás de uma flag?

Pegue o último incidente de produção que o seu time documentou e faça três perguntas. A mudança poderia ter ido para produção escondida? Uma pessoa poderia tê-la desligado em menos de um minuto, sem deploy? Um alerta teria indicado qual variante estava falhando?

Se as respostas forem não, não e não, você tem o seu primeiro candidato a flag e a primeira estimativa honesta de quanto uma reversão custa hoje. O post-mortem vai dizer o que tiver de dizer. A pergunta melhor é quanto dele você poderia ter reduzido antes de o pager disparar.