Hierarquia de feature flags na prática: modelando dependências pai-filho no useflagly em 2026

Conforme sistemas crescem e acumulam microsserviços, gerenciar toggles isolados vira uma armadilha clássica de engenharia. Aquele amontoado de condicionais espalhadas pelo código abre brechas para condições de corrida e estados quebrados no ar. Pense no caso clássico: um método de pagamento via Pix parcelado que só pode existir se o checkout transparente estiver ativo. Fazer uma requisição HTTP para cada flag satura a rede e eleva a latência sem necessidade. O UseFlagly contorna esse gargalo com o conceito de Cenários: em vez de testar flags soltas, a equipe modela árvores lógicas de dependência. Se a flag raiz estiver desligada, todo o resto da árvore cai em cascata, sem custo de processamento extra para o cliente.

Passo a passo: da modelagem ao curto-circuito no código

O primeiro passo é mapear o domínio antes de abrir o painel. Determine qual recurso funciona como habilitador primário (a flag pai) e quais são as variantes dependentes (as flags filhas). Mapeie os atributos essenciais para a regra: identifier, versão do app (appVersion), plano da conta e canal de acesso. Esse alinhamento prévio evita dependências circulares. No dashboard do UseFlagly, garanta os acessos do time — quem tem papel ADMIN define estruturas globais, enquanto perfis MEMBER trabalham nas marcas e ambientes liberados (DEV, STG ou PRD).

Com o cenário registrado e a API key configurada no ambiente da aplicação, defina a Flag Pai como o guardião central. Se o cenário for checkout-transacional, a raiz pode ser novo-fluxo-checkout, controlando, por exemplo, um rollout inicial de 20% para mobile. Depois, conecte as Flags Filhas a essa raiz, como one-click-buy-cartao e split-pagamento-pix. No editor, amarre a dependência direta: a filha só é avaliada se o pai for verdadeiro. Você ainda pode refinar as filhas com regras contextuais granulares, exigindo versão do app superior a 3.2.0 via comparador semântico (semver_gte), listas inline ou validação de intervalos.

No código da aplicação, a mágica acontece simplificando a comunicação: nada de disparar múltiplos requests. Faça uma única chamada para o microsserviço no endpoint POST /validate/scenario/:scenarioSlug passando o payload com identifier e os dados de contexto. O motor do UseFlagly resolve a árvore inteira e devolve todas as decisões em lote. Graças à combinação de cache L1 in-memory local e cache L2 distribuído em Redis, com invalidação via Pub/Sub, a resposta volta em milissegundos sem fritar sua infraestrutura.

Validação em duas pontas: lógica e resiliência de cache

Validar a árvore exige testes lógicos e testes de cache. Primeiro, simule cenários de borda via testes de integração: mande um contexto em que a flag pai resulte em false e confira se todas as filhas vieram desativadas de bate-pronto, mesmo que os parâmetros individuais delas fossem válidos. Depois, ative o pai e confira se os rollouts percentuais (calculados de forma determinística via SHA-256) e as restrições semânticas das filhas operam como deveriam.

A segunda checagem foca no cache reativo. O UseFlagly usa a chave de versão rv:<companyId> monitorada por Pub/Sub. Quando alguém mexe em uma flag no painel, o cluster recebe aviso para despejar o cache L1 na hora, evitando nós defasados. Teste o Kill Switch desligando a flag pai em tempo real e confirme a propagação instantânea. Acompanhe a telemetria: substituindo o padrão N+1 por uma consulta agregada de Cenário, a latência despenca e o blast radius fica sob controle.

Diga adeus às condições de corrida e controle dependências com precisão. Crie sua conta grátis no plano Hobby do UseFlagly em https://useflagly.com.br — cobrança 100% em Reais, sem precisar de cartão e com suporte técnico local.