"Feature flag" é usado pra descrever duas categorias de ferramenta genuinamente diferentes, e essa diferença importa mais quando um time está entregando continuamente do que parece à primeira vista.
Categoria um: flags liga/desliga com targeting
A primeira categoria, ferramentas de feature flag de propósito geral, resolve um problema real: desacoplar deploy de release. Uma flag deixa o código subir apagado, e depois ser ligado pra um segmento específico (usuários internos, um grupo de beta, um split percentual) sem um redeploy. A maioria dessas ferramentas faz bem o targeting: segmentos baseados em regra, rollout por percentual, kill switches.
O que elas tipicamente não fazem é observar nada depois que a flag é ligada. O split percentual é uma configuração estática que uma pessoa define e depois muda; não observa uma métrica nem reage a ela.
Categoria dois: rollout guiado por guardrail
A segunda categoria trata um rollout como um processo com uma política anexada, não um interruptor estático. Um rollout avança por estágios de exposição numa programação, e um guardrail avalia uma métrica real, latência, taxa de erro, uma métrica de negócio, em cada estágio. Uma violação não vira um e-mail pra alguém agir depois; ela aborta o rollout automaticamente, e a flag volta a servir a variação padrão para 100% do ambiente.
É essa a categoria pra qual o rollfuse foi construído: rollouts em estágios com guardrails e rollback automático como comportamento padrão, não um complemento colado num sistema de flags projetado só pra targeting.
Onde a linha realmente cai
As duas categorias não são hierárquicas. Um kill switch ou uma flag simples de grupo de beta não precisa de um guardrail anexado, e adicionar um seria overhead sem benefício. A linha cai no risco: qualquer release em que uma regressão chegando a 100% do tráfego seria cara o suficiente pra justificar detecção e rollback automatizados é um release que se beneficia da segunda categoria. Um release em que "alguém percebe e desliga" é um modo de falha aceitável, não se beneficia.
Na prática, a maioria dos times começa com ferramentas da categoria um (é mais simples, e muitas vezes é o que já têm), e cruza a linha depois, geralmente depois de um release que chegou a 100% do tráfego antes de alguém perceber que algo estava errado, e a correção foi uma corrida em vez de uma reversão automática.
O que checar de verdade ao avaliar qualquer uma das categorias
- A ferramenta avalia uma métrica real contra um limite, ou só deixa configurar um percentual estático?
- Se um limite é violado, algo acontece automaticamente, ou precisa de uma pessoa ver um alerta e agir?
- O rollback é uma reversão do split de tráfego, ou um redeploy completo?
Essas três perguntas separam as duas categorias de forma mais confiável do que o marketing de qualquer fornecedor.