¿Qué son los feature flags? Definición, casos de uso y errores comunes

¿Qué son los feature flags?

Un feature flag (también feature toggle, feature gate o interruptor de funcionalidad) es una condición en el código que activa o desactiva un comportamiento en tiempo de ejecución, sin un nuevo despliegue. El valor viene de un servicio de flags o de un almacén de configuración y puede variar por usuario, porcentaje de tráfico o cohorte. La idea central es separar desplegar de lanzar: el código llega a producción oculto tras un flag y después se activa de forma gradual.

if (flags.isEnabled("new-checkout", user)) {
  renderNewCheckout();
} else {
  renderOldCheckout();
}

Los cuatro casos de uso habituales

Toggles de lanzamiento

Publica el código desactivado y actívalo para el equipo, un grupo beta, el 1 % del tráfico, el 10 % y, al final, todos. Si los errores o la latencia suben en algún paso, vuelve el flag atrás en lugar de revertir una versión. Es la forma con flags del despliegue gradual de funcionalidades y combina bien con un despliegue canary (artículo en inglés).

Toggles de experimento

La mitad de los usuarios ve la variante A y la otra mitad la B; registras quién vio qué y comparas las métricas que te importan.

Toggles de permisos

Muestra una funcionalidad solo a ciertos planes, organizaciones o roles. Sirve para limitar por plan de forma sencilla; para modelos de permisos complejos usa un sistema de autorización específico.

Kill switches

Envuelve las rutas arriesgadas o costosas, como una llamada a un tercero o un paso de recomendaciones muy pesado, para poder desactivarlas durante un incidente y recurrir a algo más simple.

Cómo funciona un sistema de flags

• Definiciones centralizadas. Un panel o una API guarda cada flag y sus reglas de segmentación.
• Un SDK en tu aplicación. Obtiene los valores al arrancar o en cada petición y los guarda en una caché local, de modo que cada comprobación cuesta muy poco.
• Actualizaciones. Los cambios llegan a las aplicaciones en marcha por sondeo periódico o por un flujo push, según la herramienta.
• Un registro de auditoría. Las buenas herramientas anotan quién cambió qué flag y cuándo, y qué variante recibió cada petición.

Puedes contratarlo a un proveedor, usar una herramienta de código abierto o construir un servicio pequeño propio. La elección depende de la segmentación que necesites, de la residencia de los datos y del mantenimiento que tu equipo quiera asumir.

Errores comunes

• Flags que nunca se eliminan. Cada flag necesita un responsable y una fecha de caducidad, y quitar la ruta de código muerta forma parte de terminar la funcionalidad.
• Dependencias ocultas entre flags. El flag A solo funciona si el B está activo. Documéntalo o modélalo como requisito previo.
• Demasiadas combinaciones que probar. Diez flags booleanos independientes dan 1.024 combinaciones. Prueba activado y desactivado de cada flag, más las combinaciones que ocurren de verdad en producción.
• El servicio de flags como punto único de fallo. Tu aplicación debe seguir funcionando con valores en caché o por defecto si el servicio no responde. Compruébalo bloqueándolo, no lo des por hecho.
• Primera consulta lenta. Evalúa los flags desde una caché local, no con una llamada de red por petición.
• Flags mezclados con configuración. Los feature flags llevan decisiones de producto y de lanzamiento y cambian en ejecución. La configuración (timeouts, cadenas de conexión) y las variables de entorno son ajustes operativos que suelen cambiar con un despliegue o un reinicio.

Feature flags, pruebas de carga y monitorización

Cambiar un flag cambia qué código se ejecuta y, por tanto, la carga: una ruta nueva puede usar una base de datos o un endpoint de forma muy distinta a la anterior. Haz una prueba de carga sobre la ruta nueva antes de subir el porcentaje; LoadFocus ejecuta pruebas JMeter y k6 desde 25 regiones en la nube, y el plan gratuito incluye hasta 10 usuarios virtuales. Durante el despliegue, la monitorización de APIs comprueba de forma programada código de estado, cuerpo y tiempo de respuesta (cada 5 minutos en el plan gratuito), de modo que una regresión aparece mientras aún puedes volver el flag atrás. Vigila la latencia por variante, no solo la global.

Preguntas frecuentes sobre feature flags

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

Normalmente no. Incluso un equipo de una persona se beneficia de un kill switch y de activar antes una funcionalidad solo para sí mismo. Un flag sencillo basado en configuración basta para empezar; pasa a un servicio de flags completo cuando necesites segmentación y auditoría.

¿Qué diferencia hay entre feature flags y trunk-based development?

Se complementan. En trunk-based development los cambios pequeños se integran de forma continua en la rama principal; los feature flags permiten que el trabajo sin terminar viva ahí sin que los usuarios lo vean.

¿Cómo afectan los feature flags a las pruebas?

Prueba la ruta activada y la desactivada de cada flag, y las combinaciones que se dan en producción. Haz del estado del flag una entrada explícita de las pruebas para que los resultados sean repetibles.

¿Pueden los feature flags ralentizar mi aplicación?

Solo si se implementan mal, por ejemplo con una llamada de red en cada petición. Evalúa desde una caché en memoria que se actualiza en segundo plano y usa un valor por defecto seguro si el servicio cae.

¿Debo usar feature flags para permisos?

Para accesos sencillos por plan, sí. Para un control de acceso detallado con requisitos de auditoría, usa un sistema de autorización específico y deja los flags para decisiones de despliegue.

¿Debo enviar el estado del flag a analítica?

Sí. Añade el flag o la variante activa a tus eventos para comparar métricas por variante y distinguir el efecto del flag del ruido de fondo.