Como as flags chegam ao seu app

O seu app não chama o FortressFlag toda vez que verifica uma flag. Leituras de flag são locais — instantâneas, seguras offline, sem rede no caminho. O que viaja pela rede é um polling periódico, e o que esse polling busca depende de em qual dos dois planes você está.

O client plane: seus apps recebem respostas, não regras

Os SDKs de iOS, Android e web usam o client plane. O dispositivo envia a sua identidade e as suas tags; o FortressFlag avalia as suas regras de segmentação no servidor e devolve apenas os valores daquele dispositivo — um mapa pequeno como {"new-checkout": true, "dark-mode": false}.

O dispositivo nunca recebe as suas regras. Isso é proposital, por dois motivos: a sua lógica de segmentação (“coorte beta”, “dispositivos internos”) é assunto seu e não deveria viajar dentro de algo que qualquer pessoa pode desempacotar de um binário de app — e o payload continua minúsculo.

O client plane se autentica com uma chave de cliente (ffc_…), que viaja dentro do seu app e é pública por design — mais sobre isso em Chaves.

O server plane: seu backend recebe o ruleset

O SDK de Go usa o server plane. O seu servidor baixa o ruleset completo de um projeto + ambiente — tipos, padrões, regras, com os segmentos já achatados dentro — e avalia as flags no seu próprio processo. Uma verificação de flag é uma chamada de função sobre dados que já estão na memória: sem salto de rede por verificação, sem latência por requisição, e um polling atende o seu processo inteiro não importa quantas requisições ele trate.

Como o ruleset inclui as suas regras de segmentação, esse plane fica atrás de uma chave de servidor (ffs_…) — um segredo de verdade, tratado como uma senha de banco de dados. E como as suas regras chegam a todo servidor que tem essa chave, o corolário é seu para aplicar: não coloque segredos nem dados pessoais dos seus usuários em condições de regra.

Nesse plane não há identidade de dispositivo. O seu código passa uma chave de contexto por avaliação — um ID de usuário, um ID de sessão, o que você usar para distribuir — e a aritmética de rollout a usa exatamente como o client plane usa o ID do dispositivo, então a mesma entrada cai na mesma coorte seja qual for o plane que avalie.

Polling, e por que ele é barato

Os dois planes fazem polling em um intervalo, e os dois usam requisições condicionais: cada resposta carrega um validador (um ETag), e quando nada mudou desde o último polling, a resposta é um minúsculo “nada mudou” — sem corpo, sem reavaliação. O estado estável de uma frota que não está mudando flags é um fluxo de verificações quase de graça.

Quando você muda algo — um toggle, uma regra, um agendamento disparando — o próximo polling pega a mudança inteira. Na prática, uma mudança chega aos dispositivos cliente online em cerca de um minuto.

(Uma nota de cobrança: uma resposta “nada mudou” ainda conta como atividade para a contagem de dispositivos ativos mensais — mas lembre, um dispositivo conta uma vez por mês não importa quantas vezes consulte.)

A promessa de fallback

Uma queda do FortressFlag nunca pode derrubar o seu app. Todo SDK guarda os últimos valores que recebeu em um cache local durável e resolve flags pela mesma cascata:

Os últimos valores recebidos — mesmo de uma execução anterior. Um dispositivo que ficou offline por um mês serve o que viu por último; a desatualização é preferível a regressões surpresa.
O padrão do seu código — o valor no ponto de chamada — quando nada nunca foi recebido. (Os SDKs cliente chegam ao fundo em false para leituras booleanas sem padrão.)

Duas consequências que vale conhecer:

Uma credencial revogada ou com falha não quebra o seu app. O SDK continua servindo o seu cache e continua tentando. Erros nunca chegam aos seus usuários por uma leitura de flag.
Um payload que o SDK não consegue verificar é tratado como se não houvesse payload. Toda resposta é assinada, e o SDK confere a assinatura antes que qualquer coisa mude — veja Assinatura de payloads.
Arquivar uma flag realmente a desliga. Quando uma flag sai do payload, o SDK a remove dos valores ao vivo e do cache no mesmo polling — em cerca de um minuto, os dispositivos online em todo lugar resolvem o padrão do seu código. O cache nunca preserva flags removidas — se preservasse, arquivar não conseguiria encerrar um rollout de vez.

Para onde ir agora

Chaves — ffc_ vs ffs_, e por que uma é pública e a outra acorda alguém
Identidade do dispositivo e cobrança — o que é a identidade do client plane
Instale um SDK — escolha a sua plataforma e publique uma flag