# ¿Qué es un feature flag? La respuesta de un SRE, con código URL: https://upstreamapi.com/es/journal/que-es-un-feature-flag Type: blog Locale: es Published: 2026-10-17 Updated: 2026-10-17 --- > Un feature flag convierte una release en un control de intensidad. Qué es, sus cuatro tipos, cómo los SRE reducen el radio de impacto y cómo la deuda de flags termina pasando factura. Son las 03:12 y la tasa de errores del checkout acaba de superar el 4 %. El cambio que la provocó salió a producción hace seis horas. Nadie quiere revertir toda la release, porque también trae dos correcciones sin relación. Entonces, ¿qué es un feature flag en esta situación? Es una condición en tu código, evaluada en tiempo de ejecución, que decide si una ruta de código se ejecuta. La apagas y la nueva ruta deja de ejecutarse, sin build ni despliegue. Esa es la idea entera. Lo demás es operación. ## Qué es realmente un feature flag (y qué no es) Un feature flag es un punto de decisión. En algún lugar del código hay un `if`, y el valor que lee viene de fuera del binario: un servicio de configuración, una fila de base de datos, el SDK de un proveedor o una variable de entorno que puedes cambiar sin reiniciar. `const useNewPricing = await flags.isEnabled("new-pricing-engine", { userId: user.id, plan: user.plan, region: request.region, }); return useNewPricing ? newPricingEngine.quote(cart) : legacyPricing.quote(cart);`De ese fragmento se desprenden tres cosas. La ruta antigua tiene que seguir existiendo y tiene que seguir funcionando. El flag necesita contexto (quién pregunta) si quieres algo más inteligente que encendido o apagado. Y la evaluación está en el camino caliente de cada petición, así que su latencia y su modo de fallo ahora son tu problema. La gente usa «feature toggle» y «feature flag» como sinónimos. El nombre no importa. Lo que importa es el comportamiento: separas desplegar código de liberarlo. El código llega a producción a oscuras, y una persona o un sistema decide después quién lo ve. ## Los cuatro tipos de flag, y por qué mezclarlos duele La mayor parte del dolor con los flags viene de tratarlos todos como una sola cosa. La [taxonomía de feature toggles de Martin Fowler](https://martinfowler.com/articles/feature-toggles.html) los separa según cuánto viven y cuán dinámica es la decisión. En la práctica, se sostiene. Los release toggles son transitorios. Ocultan trabajo sin terminar tras un flag para que puedas integrar en trunk cada día. Según Fowler, deberían durar rara vez más de una o dos semanas. La decisión es estática: cada petición de una misma release recibe la misma respuesta. Los experiment toggles reparten a distintos usuarios entre variantes. Viven lo necesario para alcanzar significancia estadística, de horas a semanas, y ni un día más. La decisión se toma por petición. Los ops toggles controlan el comportamiento operativo: desactivar una función no crítica bajo carga, cambiar a una dependencia de respaldo o apagar una consulta costosa. Algunos se convierten en kill switches de larga vida. Tienen que cambiar en segundos, lo que descarta cualquier cosa que requiera una release. Los permission toggles limitan funciones según el plan o los derechos de cada usuario. Pueden vivir años, y la decisión se toma por usuario en cada petición. El error es darles a los cuatro el mismo ciclo de vida. Un permission toggle necesita un dueño y un registro de auditoría para siempre. Un release toggle necesita una fecha de borrado el día que se crea. Si no puedes saber de qué tipo es un flag mirando su nombre, tampoco podrás saber cuáles se pueden eliminar sin riesgo. ![Mano tirando de una palanca roja de parada de emergencia en un armario de control oscuro](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/fa4827-i1.webp) ## Por qué a los SRE les importa: el flag como control del radio de impacto Para un equipo de plataforma, lo interesante no es el A/B testing. Lo interesante es que un flag convierte una release en un evento en un control de intensidad. Sin flags, un despliegue expone al 100 % del tráfico el cambio de golpe. La única reversión es otro despliegue, y tarda lo que tarde tu pipeline, más el tiempo que le cuesta a una persona estar segura. Con flags, puedes exponer al 1 % de los usuarios, vigilar la tasa de errores y el p99, y subir después al 5, 25 o 50 %. El radio de impacto es el porcentaje que elegiste, y la reversión es un cambio de configuración que se propaga en segundos. Eso cambia tu tiempo medio de recuperación más que la mayoría de inversiones en herramientas. La pregunta del post-mortem deja de ser «¿por qué tardamos 40 minutos en revertir?» y pasa a ser «¿por qué no lo teníamos detrás de un flag?». Ese control de intensidad tiene una trampa. Alguien tiene que vigilar las señales y girar el control, y a las 03:12 esa persona está cansada. La versión útil de un sistema de flags ata el control a un SLO: si la tasa de errores consume una proporción fijada del error budget, el despliegue se detiene y revierte sin intervención humana. La mayoría de equipos lo construye a mano con un webhook desde su herramienta de alertas hacia la API de flags. Son unos cientos de líneas, y se paga solo la primera noche que se dispara. ## La factura llega: la deuda de flags y la lección de Knight Capital Cada flag que añades multiplica, en teoría, el número de caminos por ese código. En la práctica pruebas unas cuantas combinaciones y confías en que el resto funcione. Fowler recomienda tratar los flags como inventario con un coste de mantenimiento: crea una tarea de eliminación en el backlog al mismo tiempo que el flag, pon fechas de caducidad y, en los equipos más estrictos, haz que el build falle cuando un flag caducado siga en el código. La versión cara de esta lección es Knight Capital. El 1 de agosto de 2012, un nuevo despliegue reutilizó un flag antiguo que había controlado una función retirada. Un servidor no recibió el despliegue y siguió ejecutando el código viejo. En los primeros 45 minutos tras la apertura, el router de la firma envió más de 4 millones de órdenes al mercado mientras intentaba ejecutar 212 órdenes de clientes, como recoge la [orden de la SEC contra Knight Capital](https://www.sec.gov/newsroom/press-releases/2013-222). El artículo de Fowler señala la pérdida, de alrededor de $460 millones, como advertencia sobre los flags que no se gestionan. El flag no fue el único fallo. Un despliegue manual, la ausencia de kill switch y una detección lenta también contribuyeron. Pero la reutilización de un nombre de flag muerto es el detalle que todo equipo de plataforma debería tener colgado en la pared. Nunca reutilices un flag. Borra el antiguo, crea uno nuevo y convierte la eliminación en un paso de primera clase. ![Libreta con diagramas de flujo dibujados a mano junto a un teclado y un portátil sobre una mesa de madera](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/652884-i2.webp) ## ¿Construirlo tú o comprar una plataforma de flags? Un sistema de flags casero empieza como un archivo de configuración y un booleano. Eso sirve para la primera docena de release toggles de un servicio. Deja de servir cuando necesitas despliegues por porcentaje que mantengan la misma respuesta por usuario, reglas de segmentación, un registro de auditoría de quién cambió qué y un cambio de flag que llegue a todas las instancias en segundos, sin una avalancha sobre tu almacén de configuración. En ese punto estás comparando plataformas con criterios medibles: latencia de evaluación del SDK (evaluación local frente a llamada de red), streaming frente a polling para las actualizaciones, granularidad de las reglas de targeting, soporte multientorno y cómo escala el medidor de precios con tu tráfico. Los medidores se diferencian más que las listas de funciones. LaunchDarkly es la implementación de referencia de la categoría: targeting maduro, releases protegidas y una amplia superficie de integración. Sus planes por uso cobran por conexión de servicio y por cada mil usuarios activos mensuales del lado cliente, así que una app de consumo con una audiencia anónima grande puede ver la factura moverse de formas que un equipo solo de backend no notaría. El argumento a favor es real: si necesitas gobernanza y auditoría a escala empresarial, es la opción que más tiempo ha tenido para endurecerse. Statsig agrupa flags con experimentación y analítica de producto, y cobra por evento. Encaja con equipos que tratan los flags sobre todo como una superficie de experimentos. Si tu caso de uso son sobre todo ops toggles y kill switches, pagas por una analítica que quizá no lees. Ten en cuenta también que el proveedor ha cambiado de dueño dos veces desde septiembre de 2025, algo que conviene anotar en tu revisión de riesgo de proveedores. Elijas el que elijas, prueba el modo de fallo antes de firmar. Bloquea el acceso de red del SDK en staging y comprueba qué hace la aplicación. Un buen SDK sirve los últimos valores conocidos desde caché y registra el problema con claridad. Uno malo bloquea la ruta de la petición. ## La observabilidad es la mitad del sistema de flags Un flag sin telemetría es una suposición. La configuración mínima útil adjunta el estado del flag a cada traza y cada línea de log de la petición, para que cuando aparezca un pico de errores puedas agrupar por variante del flag y ver si la nueva ruta es la causa. Datadog y otras plataformas todo en uno facilitan el desglose por variante una vez que tu SDK etiqueta los spans. La salvedad es que la facturación por host y por señal crece deprisa cuando añades etiquetas de alta cardinalidad, como la clave del flag más la variante más el segmento de usuario. Elige con cuidado qué dimensiones etiquetas. Grafana es la vía más barata si ya usas Prometheus y OpenTelemetry. Tendrás que construir tú los dashboards con flags, lo que cuesta tiempo de ingeniería, pero te da control total sobre las etiquetas que emites. Para un equipo de entre 50 y 500 ingenieros con un grupo de plataforma, esa compensación suele ser la correcta. ![Ingeniero caminando por un pasillo de racks de servidores iluminado en azul y ámbar](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/3ea456-i3.webp) ## Un runbook corto para tu primer flag en producción Si vas a introducir flags en un equipo que no los tiene, mantén el primer despliegue aburrido. - Elige un cambio con una métrica de éxito clara, como la tasa de errores del checkout o el p99 de un endpoint. - Nombra el flag con su tipo y su dueño, por ejemplo `release.checkout.new-tax-calc.owner-payments`. - Escribe la tarea de eliminación ahora y fija una fecha de caducidad no más lejana de dos semanas. - Despliega al 1 %, mantén un ciclo completo de tráfico y luego sube. Define de antemano el umbral al que revertirás. - Haz que la reversión sea un único comando o botón, y ensáyala una vez en staging antes de necesitarla de noche. - Cuando el 100 % haya aguantado unos días, borra el flag y el camino de código antiguo en el mismo cambio. La parte poco vistosa es el paso 6. Los equipos que lo saltan acaban con cientos de flags, nadie sabe qué hace la mitad de ellos y un riesgo con forma de Knight Capital en el repositorio. ## ¿Cómo habría sido tu último incidente detrás de un flag? Toma el último incidente de producción que tu equipo documentó y hazte tres preguntas. ¿Podría el cambio haber salido a oscuras? ¿Podría una persona desactivarlo en menos de un minuto sin desplegar nada? ¿Te habría avisado una alerta de qué variante fallaba? Si las respuestas son no, no y no, tienes tu primer candidato a flag y tu primera estimación honesta de lo que cuesta revertir hoy. El post-mortem dirá lo que tenga que decir. La pregunta mejor es cuánto de ese incidente podrías haber hecho más pequeño antes de que saltara la alerta de guardia. ## FAQ ### ¿Qué es un feature flag en pocas palabras? Es una condición en tu código que decide si una ruta de código se ejecuta. El valor llega desde fuera del binario, por ejemplo desde un servicio de configuración o un SDK de proveedor, así que puedes cambiar el comportamiento sin un nuevo despliegue. ### ¿Cuál es la diferencia entre un feature flag y un feature toggle? En la práctica, ninguna. Ambos nombres describen el mismo mecanismo. Algunos proveedores usan toggle para la práctica y flag para la implementación en el código, pero los equipos usan los términos como sinónimos. ### ¿Cuáles son los principales tipos de feature flags? Se distinguen cuatro: release toggles para ocultar trabajo sin terminar, experiment toggles para las pruebas A/B, ops toggles para el control en tiempo de ejecución como los kill switches, y permission toggles para limitar funciones por plan o derechos. Cada uno tiene una vida útil esperada distinta. ### ¿Cuánto debe vivir un feature flag? Depende del tipo. Los release toggles deberían eliminarse normalmente en una o dos semanas. Los experiment toggles viven lo que tarden en alcanzar significancia. Los kill switches de operaciones y los permission toggles pueden durar años, siempre con un dueño claro. ### ¿Qué es un kill switch en software? Es un ops flag de larga vida que permite a un operador desactivar al instante una función o dependencia en producción, sin desplegar. Se usa para degradar el servicio con elegancia bajo carga o para detener un cambio que falla. ### ¿Conviene construir nuestro propio sistema de flags o comprar uno? Un archivo de configuración y un booleano bastan para unos pocos release toggles en un servicio. Cuando necesites despliegues por porcentaje que mantengan la misma respuesta por usuario, segmentación, registros de auditoría y propagación rápida entre instancias, compara plataformas por latencia del SDK, mecanismo de actualización, granularidad de targeting y cómo escala el medidor de precios. ### ¿Pueden los feature flags causar caídas? Sí. Reutilizar el nombre de un flag antiguo, dejar rutas de código muertas y combinaciones de flags sin probar son causas habituales. El incidente de Knight Capital en 2012 implicó un flag reutilizado. Trata los flags como inventario con fechas de caducidad y nunca reutilices uno.