¿Qué son los Feature Flags?

¿Qué son los feature flags?

Los feature flags (también llamados feature toggles, feature gates o release toggles) son comprobaciones condicionales en código que activan o desactivan el comportamiento de la aplicación en producción sin redesplegar. La comprobación se ve como if (featureFlags.newCheckoutFlow) { /* nuevo código */ } else { /* código viejo */ }. El valor de newCheckoutFlow se obtiene en runtime desde un servicio de flags — LaunchDarkly, ConfigCat, GrowthBook o tu propio sistema casero — y puede cambiar instantáneamente para cualquier usuario, porcentaje de tráfico o cohorte específico.

La idea central: deploy ≠ release. Sin flags, enviar código significa hacerlo en vivo para todos. Con flags, el código puede enviarse a producción detrás de un flag, permanecer oscuro durante semanas mientras lo afinas internamente, luego progresivamente desplegarse al 1%, 5%, 50%, 100% de los usuarios. Si algo se rompe, vuelves el flag. Sin redespliegue, sin rollback, sin pánico.

Los cuatro casos de uso canónicos

1. Toggles de release (rollout gradual)

Envía código a producción detrás de un flag, apagado por defecto. Habilita gradualmente para usuarios internos → cohorte beta → canary 1% → 10% → 100%. Si las métricas se degradan en cualquier etapa (errores se disparan, conversión cae, latencia p95 sube), vuelve el flag instantáneamente. Sin flags, necesitarías redesplegar o hacer git-revert para recuperar.

2. Toggles de experimento / test A/B

50% de usuarios ven la versión A, 50% ven la versión B. El servicio de flags traquea qué usuario obtuvo qué variante. Analítica correlaciona acciones de usuario con variante. Análisis estadístico decide el ganador. Las grandes plataformas de experimentación (Optimizely, LaunchDarkly Experiments) se construyen completamente sobre este primitivo.

3. Toggles de permisos / entitlements

Diferentes usuarios ven diferentes features basadas en su tier de plan, organización o rol. Las features "solo plan Pro" están gateadas por flags; el valor del flag depende del estado de la cuenta del usuario. Funcionalmente similar a la autorización tradicional pero gestionado en el mismo dashboard de flags que los releases.

4. Kill switches (toggles operacionales)

Envuelve rutas de código riesgosas o caras (llamadas API a terceros, motores de recomendación, inferencia ML) en flags para poder deshabilitarlas bajo carga o durante incidentes. ¿El sitio está fallando porque la API de recomendaciones está haciendo timeout? Vuelve el flag, recurre a una experiencia más simple, lidia con el tercero con calma.

Cómo funcionan los sistemas de feature flags

La arquitectura bajo el capó:

• Definiciones de flags almacenadas centralmente. Un dashboard web permite a los equipos de producto/ingeniería definir flags, establecer reglas de targeting ("100% de usuarios en UE", "10% de usuarios con plan=pro", "esta lista específica de user_id") y activar/desactivar.
• SDKs cliente en tu aplicación. Tu app obtiene los valores de flags del servicio o al inicio (cacheado en memoria) o por petición (típicamente con caché local agresiva). Existen SDKs para todos los lenguajes y frameworks principales.
• Updates por streaming. Los servicios de flags modernos usan WebSockets o Server-Sent Events para empujar cambios de valores de flag a los clientes en ejecución en milisegundos. Cambias el flag en el dashboard; el tráfico de producción se mueve segundos después.
• Telemetría de vuelta. Los servicios de flags capturan qué valores de flag sirvieron qué peticiones, permitiendo auditoría ("¿quién cambió este flag a las 03:42?") y experimentación (correlacionar comportamiento de usuario con variante).

Build vs buy: las cuatro opciones reales

• Buy: LaunchDarkly. El líder de mercado. Ecosistema SDK maduro, targeting sofisticado, caro a escala (1k-50k+ $/año). Opción pay-for-confidence.
• Buy: ConfigCat / Flagsmith / Statsig. Alternativas más baratas, sets de features decentes, más rápidas de evaluar. ConfigCat tiene un nivel gratis generoso; Flagsmith es open-source-y-self-host-friendly.
• Buy: GrowthBook (open source). Particularmente fuerte para casos de uso de experimentación. Self-host o usa la versión SaaS.
• Build: in-house. Un servicio de flags simple es ~500 líneas de código: definiciones de flags en una base de datos, una API para obtenerlos, un dashboard, reglas básicas de targeting. Vale la pena construirlo si tienes requisitos de cumplimiento específicos (los datos deben permanecer en tu VPC) o las necesidades de tu equipo son estrechas. La mayoría de equipos subestiman el mantenimiento a largo plazo.

Trampas comunes de feature flags

• Explosión de flags. Sin gobernanza, los equipos envían flags pero nunca los borran. Después de un año, el codebase tiene 200 flags, la mitad de los cuales ya no se necesitan. Establece una política: cada flag tiene una fecha de expiración y un owner; la limpieza es parte de la definición-de-hecho del release.
• Acoplamiento oculto entre flags. El Flag A solo tiene sentido cuando el Flag B está activado. Sin dependencias explícitas, un compañero apaga B y rompe A. Mantén las relaciones de flags documentadas; considera una feature de "flag compuesto" en el servicio.
• Explosión de matriz de testing. 10 flags booleanos independientes = 1024 rutas de código posibles. No vas a hacer QA de todos. Usa flags prerrequisito, testea las combinaciones más usadas y confía en la observabilidad de producción para atrapar el resto.
• Latencia en cold cache. El primer fetch de flag al inicio de la app bloquea la petición. Pre-calienta el caché, usa SDKs de streaming o recurre a defaults seguros si el servicio de flags no es alcanzable.
• Servicio de flags como punto único de fallo. Si el servicio de flags cae, tu app debe seguir funcionando. Los SDKs típicamente cachean los últimos valores conocidos buenos y recurren con elegancia — pero verifica que esto sea cierto y testealo (ejecuta un experimento de chaos que bloquee las llamadas de red al servicio de flags).
• Atascado en flag-purgatorio. Flag va de 0% → 50% → atascado. El owner cambia de equipo, el flag nunca llega al 100%. La mitad de limpieza es más difícil que la mitad de rollout. Constrúyelo en tu proceso o te ahogarás en cruft.

Feature flags vs config flags vs environment variables

Tres conceptos relacionados:

• Feature flags: Mutables en runtime, a menudo targeteados por usuario, a veces A/B testeados. Impulsados por un servicio de flags.
• Config flags: Configuración de aplicación (strings de conexión a base de datos, claves API, timeouts). Normalmente establecidos por entorno, cambiados vía redeploy o config-reload.
• Environment variables: Configuración a nivel de OS. Fundamental pero inflexible — los cambios requieren reinicio de proceso.

No los confundas. Los feature flags son para decisiones de producto/release; el config es para parámetros operacionales; las environment variables son para bootstrap del sistema.

FAQ: Feature Flags

¿Son los feature flags exagerados para equipos pequeños?

Ya no. Herramientas como ConfigCat tienen niveles gratis usables para equipos pequeños. Incluso un dev shop individual se beneficia de kill switches y rollouts graduales. El overhead de un servicio de flags es pequeño comparado con el coste de apagar incendios de un mal release.

¿Cuál es la diferencia entre feature flags y trunk-based development?

Son complementarios. Trunk-based development significa que cada commit va a main; los feature flags te permiten mantener código incompleto en main de forma segura sin que los usuarios lo vean. Juntos permiten integración continua sin ramas de larga vida.

¿Cómo afectan los feature flags al testing?

Testea la ruta flag-on Y la ruta flag-off. Builds de matriz CI con ambos estados. Para sistemas multi-flag, prioriza las combinaciones realmente usadas en producción. Algunos servicios de flags (LaunchDarkly, Statsig) se integran con test runners para inyectar estados específicos de flag para testing.

¿Pueden los feature flags dañar el rendimiento?

Si se implementan mal, sí — obtener un valor de flag en cada petición sin cachear añade latencia. Los SDKs modernos cachean agresivamente (en memoria) y actualizan vía streaming, así que el coste por petición es de microsegundos, no milisegundos. Audita tu setup de SDK si la latencia de flag parece alta.

¿Debería usar feature flags para permisos?

Opinión dividida. Pros: el mismo dashboard para releases + entitlements. Contras: los servicios de flags típicamente no están construidos para ACL fina con rastros de auditoría. Para modelos de permisos complejos, usa un servicio dedicado de authz (Permit.io, OpenFGA, AWS Cedar). Para gating simple por tier de plan, los flags están bien.

¿Cómo interactúan los feature flags con la analítica?

Mejor práctica: envía el estado activo del flag (o la variante del experimento) como propiedad de evento a tu herramienta de analítica. Esto te permite cortar métricas por variante y confirmar que los experimentos son estadísticamente válidos. Sin esto, no puedes decir si una caída de métrica se debe a un cambio de flag o ruido orgánico.

Cómo se relaciona LoadFocus con los rollouts de feature flags

Los rollouts de feature flags son exactamente cuando las pruebas de carga importan más. Las nuevas rutas de código activadas para el 10% del tráfico podrían de repente martillar endpoints caros de manera diferente al código viejo. Las pruebas de carga LoadFocus contra la nueva ruta de código antes del flag flip validan que aguanta a escala. La monitorización de API durante el rollout atrapa regresiones de latencia en tiempo real para que puedas volver el flag antes de que los usuarios lo noten.