Como implementar feature toggles em arquiteturas de microservices

1. Fundamentos e estratégias de feature toggles em microservices

Feature toggles (também chamados de feature flags) são mecanismos que permitem ativar ou desativar funcionalidades em tempo de execução sem necessidade de novo deploy. Em arquiteturas de microservices, eles se dividem em quatro categorias principais:

  • Release toggles: controlam quando uma funcionalidade entra em produção
  • Experiment toggles: habilitam testes A/B e experimentos controlados
  • Ops toggles: gerenciam aspectos operacionais como degradação de serviço
  • Permission toggles: liberam funcionalidades por perfil de usuário

Os desafios específicos em ambientes distribuídos incluem latência na propagação de mudanças, consistência de estado entre serviços e sincronização de configurações. A escolha entre armazenamento centralizado (ex.: etcd, Consul) vs. descentralizado (ex.: arquivos locais com sincronização via git) depende do trade-off entre consistência imediata e resiliência a falhas de rede.

# Exemplo de configuração de toggle em YAML
features:
  novo-sistema-pagamento:
    type: release
    enabled: true
    rollout_percentage: 25
    environments: [staging, production]
    owners: ["time-pagamentos"]

2. Arquitetura de gerenciamento de feature flags

Um serviço central de feature flags deve ser projetado com cache distribuído para reduzir latência. Redis ou etcd são escolhas comuns, armazenando pares chave-valor com TTL configurável.

O padrão de comunicação push (ex.: WebSocket, SSE) oferece atualização quase em tempo real, enquanto pull (ex.: polling a cada 30s) é mais simples e resiliente. Uma estratégia híbrida combina push para mudanças críticas com pull periódico como fallback.

Para degradação graciosa, cada microservice deve armazenar um cache local com valores padrão. Quando o serviço de flags está indisponível, o sistema continua operando com a última configuração válida conhecida.

# Configuração de fallback no cliente de feature flags
feature_flag_client:
  cache_ttl: 60s
  fallback_behavior: last_known_value
  default_values:
    novo-sistema-pagamento: false
    relatorio-v2: true
  retry_config:
    max_attempts: 3
    backoff: exponential

3. Implementação de toggles no código dos microservices

A injeção de dependência permite abstrair a lógica de feature flags. Cada serviço recebe um cliente configurado que consulta o serviço central ou cache local.

Middleware em APIs REST ou em consumers de filas (ex.: RabbitMQ) aplica toggles em tempo de execução, decidindo se uma requisição deve ser processada pelo novo fluxo ou pelo legado.

Para evitar "flag hell", adote versionamento semântico de toggles, planeje remoção programada (ex.: 90 dias após estabilização) e documente testes A/B com métricas claras.

# Exemplo de middleware REST para feature toggle
@app.middleware("http")
async def feature_toggle_middleware(request: Request, call_next):
    if request.url.path.startswith("/api/v2/pagamentos"):
        if await feature_flags.is_enabled("novo-sistema-pagamento", request.user):
            response = await call_next(request)
        else:
            response = RedirectResponse(url="/api/v1/pagamentos")
    else:
        response = await call_next(request)
    return response

4. Sincronização e consistência entre serviços

A propagação de mudanças de toggles com eventos assíncronos (ex.: Apache Kafka, RabbitMQ) garante que todos os serviços sejam notificados, mesmo em caso de falha temporária. Cada serviço consome eventos de toggle e atualiza seu cache local.

Inconsistências temporárias são aceitáveis em sistemas eventualmente consistentes. Para fluxos multi-serviço que exigem atomicidade, utilize sagas com compensação ou transações distribuídas (ex.: padrão Outbox com CDC).

# Exemplo de evento de toggle no Kafka
{
  "event_type": "feature_toggle_changed",
  "timestamp": "2025-03-15T10:30:00Z",
  "toggle_name": "novo-sistema-pagamento",
  "new_value": true,
  "rollout_percentage": 50,
  "changed_by": "admin@empresa.com"
}

5. Segurança e controle de acesso a feature toggles

A alteração de flags em produção deve exigir autenticação forte (ex.: OAuth2 com MFA) e autorização baseada em papéis (RBAC). Apenas engenheiros seniores e SREs devem ter permissão para modificar toggles críticos.

Todas as mudanças devem ser auditadas com logging estruturado, registrando quem alterou, quando, qual toggle e o valor anterior. O isolamento por ambiente (dev, staging, production) evita que alterações de teste impactem produção.

A granularidade por tenant ou usuário permite liberar funcionalidades gradualmente, ideal para testes A/B e rollouts controlados.

# Política de acesso para feature toggles
access_policies:
  admin:
    can_create: true
    can_enable_production: true
    requires_approval: false
  developer:
    can_create: true
    can_enable_production: false
    requires_approval: true
  viewer:
    can_view: true
    can_modify: false

6. Monitoramento e observabilidade de toggles

Métricas essenciais incluem taxa de ativação por flag, impacto em latência (p95, p99), taxa de erros e cobertura de usuários. Dashboards no Grafana ou Datadog devem mostrar a saúde de cada toggle.

Alertas devem disparar quando um toggle órfão (sem código associado) é detectado ou quando uma flag causa degradação inesperada. Integração com OpenTelemetry permite rastrear decisões de toggles em chamadas distribuídas, adicionando spans com o nome da flag e valor avaliado.

# Métrica exportada para Prometheus
# HELP feature_toggle_activation_count Total de ativações por toggle
# TYPE feature_toggle_activation_count counter
feature_toggle_activation_count{toggle="novo-sistema-pagamento",environment="production"} 15234

7. Estratégias de rollout e reversão com feature toggles

Canary releases usando toggles de ambiente permitem liberar uma funcionalidade para 1% dos usuários, depois 5%, 25%, 50% e 100%, monitorando SLOs a cada etapa.

A automação de rollback deve ser acionada quando métricas de saúde (ex.: taxa de erro > 1%, latência p95 > 500ms) ultrapassam thresholds predefinidos. Ferramentas como Flagr ou LaunchDarkly oferecem rollback automático.

A limpeza de toggles é crítica: após 30-90 dias de estabilização, remova o código morto. Scripts automatizados podem detectar toggles não referenciados e gerar tarefas de remoção.

# Script de limpeza de toggles órfãos
#!/bin/bash
echo "Verificando toggles não utilizados..."
for toggle in $(list_all_toggles); do
  if ! grep -r "$toggle" --include="*.py" --include="*.java" > /dev/null; then
    echo "Toggle $toggle não referenciado - agendando remoção"
    create_cleanup_task "$toggle" "remover em 7 dias"
  fi
done

Referências