Cómo llegan los flags a tu app

Tu app no llama a FortressFlag cada vez que comprueba un flag. Las lecturas de flags son locales — instantáneas, seguras sin conexión, sin red por el camino. Lo que viaja por la red es un sondeo periódico, y qué obtiene ese sondeo depende de en cuál de los dos planos estés.

El plano de cliente: tus apps reciben respuestas, no reglas

Los SDK de iOS, Android y web usan el plano de cliente. El dispositivo envía su identidad y sus etiquetas; FortressFlag evalúa tus reglas de targeting en el servidor y devuelve solo los valores de ese dispositivo — un mapa pequeño como {"new-checkout": true, "dark-mode": false}.

El dispositivo nunca recibe tus reglas. Es deliberado, por partida doble: tu lógica de targeting («cohorte beta», «dispositivos internos») es asunto tuyo y no debería viajar dentro de algo que cualquiera puede desempaquetar de un binario de app — y la carga útil se mantiene diminuta.

El plano de cliente se autentica con una clave de cliente (ffc_…), que viaja dentro de tu app y es pública por diseño — más sobre eso en Claves.

El plano de servidor: tu backend recibe el ruleset

El SDK de Go usa el plano de servidor. Tu servidor descarga el ruleset completo de un proyecto + entorno — tipos, valores por defecto, reglas, con los segmentos ya aplanados dentro — y evalúa los flags en su propio proceso. Una comprobación de flag es una llamada a una función sobre datos que ya están en memoria: sin salto de red por comprobación, sin latencia por petición, y un solo sondeo sirve a todo tu proceso sin importar cuántas peticiones atienda.

Como el ruleset incluye tus reglas de targeting, este plano está detrás de una clave de servidor (ffs_…) — un secreto de verdad, tratado como una contraseña de base de datos. Y como tus reglas llegan a cada servidor que tenga esa clave, el corolario te toca aplicarlo a ti: no pongas secretos ni datos personales de tus usuarios en las condiciones de las reglas.

En este plano no hay identidad de dispositivo. Tu código pasa una clave de contexto por evaluación — un ID de usuario, un ID de sesión, lo que uses para repartir — y la aritmética de rollout la usa exactamente igual que el plano de cliente usa el ID de dispositivo, así que la misma entrada cae en la misma cohorte sea cual sea el plano que la evalúe.

El sondeo, y por qué es barato

Ambos planos sondean a intervalos, y ambos usan peticiones condicionales: cada respuesta lleva un validador (un ETag), y cuando nada ha cambiado desde el último sondeo, la respuesta es un diminuto «nada ha cambiado» — sin cuerpo, sin reevaluación. El estado estable de una flota que no está cambiando flags es un flujo de comprobaciones casi gratuitas.

Cuando sí cambias algo — un cambio de estado, una regla, una programación que se dispara — el siguiente sondeo lo recoge por completo. En la práctica, un cambio llega a los dispositivos cliente conectados en aproximadamente un minuto.

(Una nota de facturación: una respuesta de «nada ha cambiado» sigue contando como actividad para el recuento de dispositivos activos mensuales — pero recuerda, un dispositivo cuenta una vez al mes sin importar cuántas veces sondee.)

La promesa de respaldo

Una caída de FortressFlag nunca debe tumbar tu app. Cada SDK guarda los últimos valores que recibió en una caché local duradera y resuelve los flags a través de la misma cascada:

1. Los últimos valores recibidos — incluso de una ejecución anterior. Un dispositivo que ha estado un mes sin conexión sirve lo último que vio; se prefiere lo desactualizado a las regresiones sorpresa.
2. El valor por defecto de tu código — el valor en el punto de llamada — cuando nunca se ha recibido nada. (Los SDK de cliente terminan en false para lecturas booleanas sin valor por defecto.)

Dos consecuencias que conviene conocer:

• Una credencial revocada o que falla no rompe tu app. El SDK sigue sirviendo su caché y sigue intentándolo. Los errores nunca llegan a tus usuarios a través de una lectura de flag.
• Una carga útil que el SDK no puede verificar se trata como si no hubiera carga útil. Cada respuesta va firmada, y el SDK comprueba la firma antes de que cambie nada — mira Firma de payloads.
• Archivar un flag lo apaga de verdad. Cuando un flag sale de la carga útil, el SDK lo elimina de los valores activos y de la caché en el mismo sondeo — en aproximadamente un minuto, los dispositivos conectados de todas partes resuelven el valor por defecto de tu código. La caché nunca conserva flags eliminados — si lo hiciera, archivar no podría terminar un rollout para siempre.

¿Por dónde seguir?

• Claves — ffc_ frente a ffs_, y por qué una es pública y la otra despierta a alguien
• Identidad del dispositivo y facturación — qué es la identidad del plano de cliente
• Instala un SDK — elige tu plataforma y publica un flag