Pular para o conteúdo

apps/scalability/feature-toggle

141 · Escalabilidade & Infraestrutura · ≈ 6 min de estudo

Feature Toggle

Separa deploy de release: o código vai para produção desligado e a decisão de ligar, para quem e quando, fica numa tabela que o serviço lê em tempo de execução. Cada toggle tem um tipo que fixa seu ciclo de vida — release (temporário, com dono e data de remoção), ops (kill switch) e permission (por plano). Use para liberar aos poucos, desligar em segundos num incidente e restringir recursos por plano.

Veja também: architecture/feature-flags — flags com OpenFeature e invalidação por Redis.

passos
6
arquivos
3
testes
0
tecnologias
4
Infraestrutura realTypeScriptBunPostgreSQLDocker
Baixar cartão

Cenário

O banco digital libera o PIX Automático para 10% dos clientes e depois 50%, sem que ninguém já incluído saia; num incidente, desliga o saque via PIX para todos imediatamente; oferece investimentos avançados só aos planos premium; e cobra do time dono os toggles de release que passaram da data de remoção.

Planta

Fluxo
7/7
Time muda o togglePostgreSQLfeature_togglesLISTEN no servicoSnapshot localTimer de segurancaRequisicao do clientevalor e motivopadrao: falseUPDATEtrigger pg_notifyrecarregarecarregaevaluate chave,cliente, planorelease: bucketsha256 menor queo percentualops: ligadoou desligadopermission:plano na listatoggle ausenteou banco fora
7

7 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Chave em runtime ativa o recurso.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

  1. 01

    O serviço guarda um snapshot local e avalia cada toggle em memória; um trigger faz pg_notify a cada mudança, e o LISTEN recarrega o snapshot na hora — um timer lento é só rede de segurança

  2. 02

    ReleaseBucket estável de 0 a 99 por sha256(chave:cliente); o cliente entra quando o percentual passa do seu bucket e continua dentro quando o percentual sobe

  3. 03

    OpsLiga ou desliga para todos, propagado em milissegundos — kill switch não espera cache expirar

  4. 04

    PermissionHabilita pelo plano do cliente; não substitui autorização nas rotas

  5. 05

    Toggle ausente, desligado ou banco inacessível sem snapshot respondem false, o comportamento antigo; com snapshot, a última versão continua valendo

  6. 06

    A primeira exposição de cada cliente ao caminho novo é registrada; release sem remove_by é recusado pelo banco, e os vencidos saem no relatório

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Liga, desliga e amplia sem deploy

  • Kill switch chega a todas as instâncias na hora

  • Bucket estável mantém cada cliente na mesma versão

  • Banco fora não liga nada por acidente

Custos

  • Cada toggle é um caminho a mais para testar

  • Uma conexão dedicada ao LISTEN por instância

  • Toggle esquecido vira condicional permanente

  • Com o banco fora, mudanças esperam ele voltar

apps/scalability/feature-toggle

3 arquivos

src/

  • toggle_evaluate.tsAvaliação pura: padrão seguro, bucket estável, rollout, plano
  • toggle_store.tsSnapshot local, LISTEN/NOTIFY, timer de segurança, exposição e relatório de vencidos

sql/

  • 01_schema.sqlschemaToggles com tipo e ciclo de vida, trigger de notificação e exposições

Executar · com Docker

  1. ./docker.sh up# sobe PostgreSQL
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário
  5. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
PostgreSQL

Por que se relacionam

Teste rápido

Qual é o próximo passo depois de Feature Toggle?

Próximo projeto · Escalabilidade & InfraestruturaLeader Election
Esc

↑ ↓ navegarEnter abrir191 resultados