Passo a passo de um serviço de feature flags: rulesets, avaliação local e rollouts percentuais estáveis

Objetivo

Avaliar as flags de forma consistente em todos os serviços, alterá-las sem fazer deploy, fazer rollouts por porcentagem sem que os usuários alternem entre variantes e manter a avaliação funcionando quando o serviço de flags estiver fora do ar.

Pré-requisitos

Uma lista de ambientes, os atributos disponíveis para segmentação (user id, tenant, região, versão do app) e um acordo de que as flags expiram, a menos que sejam marcadas como operacionais.

Passos

1. Restrições: a avaliação é local e barata; o mesmo sujeito recebe a mesma variante em todos os serviços; toda alteração é atribuível a um autor; os SDKs do lado do cliente não podem receber regras que revelem dados de segmentação.
2. Componentes: um repositório de definições com uma API de administração; um distribuidor que serve o ruleset completo de cada ambiente, com versão e ETag, por polling ou streaming; SDKs que fazem cache do ruleset e avaliam localmente; uma convenção para o contexto de avaliação, que a especificação OpenFeature descreve como informação ambiente para a avaliação de flags, usada em segmentação, overrides e avaliação fracionária; um log de alterações.
3. Modelo de dados: flag(key, env, type, variants[], default_variant, enabled, rules[], version, owner, expires_at); rule(conditions[], variant | rollout{variant: percent}); change(flag, env, author, before, after, at); servido como um único documento ruleset(env, version, flags[]).
4. Rollouts estáveis: aplique um hash a flag_key + subject_key para obter um bucket de 0 a 9999 e compare-o com a porcentagem do rollout; usar o mesmo hash em todos os SDKs mantém o sujeito na sua variante entre serviços e à medida que a porcentagem aumenta. Nunca sorteie um número aleatório a cada avaliação.
5. Modos de falha: distribuidor fora do ar (os SDKs mantêm o último ruleset na memória e em disco e recorrem aos valores padrão do código apenas em um cold start); defasagem de versão entre serviços por alguns segundos após uma alteração (aceite; para decisões que precisam coincidir, avalie uma única vez na borda e repasse o resultado); navegadores ou apps móveis recebendo o ruleset completo (sirva valores pré-avaliados a clientes não confiáveis); flags que nunca expiram (reporte avaliações por flag e idade); uma regra que referencia um atributo ausente do contexto (defina o fallthrough explicitamente).
6. Medição: tempo de propagação do ruleset, avaliações por flag por dia (zero significa flag morta), proporção de avaliações que usaram os valores padrão, flags com expires_at vencido, alterações por dia por autor.
7. Fica para depois: estatísticas de experimentos, um construtor visual de regras, dependências entre flags, overrides por requisição, alterações agendadas.

Resultado esperado

Uma alteração chega a todos os serviços dentro do limite de propagação, nenhum sujeito alterna de variante durante um rollout, e uma queda do serviço de flags deixa cada serviço com o último ruleset conhecido.

Limites e base de verificação

Design proposto, sem medições. Os tipos de toggle e a disciplina de limpeza estão no artigo sobre feature toggles; este passo a passo cobre o serviço e o contrato do seu SDK.