Aprende a diseñar y construir una web app para crear feature flags, segmentar usuarios, ejecutar rollouts graduales, añadir un kill switch y rastrear cambios de forma segura.
Una feature flag (también llamada “feature toggle”) es un control simple que te permite activar o desactivar una capacidad del producto sin desplegar código nuevo. En lugar de ligar un lanzamiento a un deploy, separas “el código está desplegado” de “el código está activo”. Ese pequeño cambio altera cuánto y con qué rapidez puedes entregar con seguridad.
Los equipos usan feature flags porque reducen el riesgo y aumentan la flexibilidad:
El valor operativo es simple: las feature flags te dan una forma rápida y controlada de responder al comportamiento del mundo real—errores, regresiones de rendimiento o feedback negativo—sin esperar un ciclo completo de redeploy.
Esta guía te acompaña en la construcción de una web app práctica para gestión de feature flags y rollouts con tres partes centrales:
El objetivo no es una plataforma empresarial masiva; es un sistema claro y mantenible que puedas poner delante de un equipo de producto y confiar en producción.
Si quieres prototipar rápidamente esta clase de herramienta interna, un flujo de trabajo de prototipado puede ayudar. Por ejemplo, los equipos suelen usar Koder.ai para generar una primera versión funcional del dashboard en React y una API en Go/PostgreSQL a partir de una especificación de chat estructurada, y luego iterar en el motor de reglas, RBAC y requisitos de auditoría en modo planificación antes de exportar el código fuente.
Antes de diseñar pantallas o escribir código, aclara para quién es el sistema y qué significa “éxito”. Las herramientas de feature flag suelen fallar no porque el motor de reglas esté mal, sino porque el flujo de trabajo no coincide con cómo los equipos entregan y soportan software.
Los ingenieros quieren controles rápidos y predecibles: crear una flag, añadir reglas de segmentación y desplegar sin redeploy. Los product managers quieren la confianza de que los lanzamientos pueden ser escalonados y programados, con visibilidad clara de quién está afectado. Soporte y operaciones necesitan una forma segura de responder a incidentes—idealmente sin alertar a ingeniería—desactivando rápido una funcionalidad riesgosa.
Un buen documento de requisitos nombra estas personas y las acciones que deben poder realizar (y no realizar).
Concéntrate en un núcleo estrecho que permita rollout gradual y rollback:
Estas no son “agradables extras”—son lo que hace que una herramienta de rollouts valga la pena.
Registra estas ideas ahora, pero no las construyas primero:
Escribe requisitos de seguridad como reglas explícitas. Ejemplos comunes: aprobaciones para cambios en producción, auditabilidad completa (quién cambió qué, cuándo y por qué) y una vía rápida de rollback disponible incluso durante un incidente. Esta “definición de seguro” guiará decisiones posteriores sobre permisos, fricción en la UI e historial de cambios.
Un sistema de feature flags es más fácil de razonar cuando separas “gestionar flags” de “servir evaluaciones”. Así la experiencia de administración puede ser agradable y segura, mientras tus aplicaciones obtienen respuestas rápidas y fiables.
A alto nivel, querrás cuatro bloques de construcción:
Un modelo mental simple: el dashboard actualiza definiciones de flags; las aplicaciones consumen una snapshot compilada de esas definiciones para una evaluación rápida.
Generalmente tienes dos patrones:
Evaluación server-side (recomendado para la mayoría de flags). Tu backend pregunta al SDK/capa de evaluación usando un objeto user/context, y luego decide qué hacer. Esto mantiene reglas y atributos sensibles fuera del cliente y facilita aplicar un comportamiento consistente.
Evaluación client-side (usar selectivamente). Un cliente web/móvil obtiene una configuración pre-filtrada y firmada (solo lo que el cliente puede conocer) y evalúa localmente. Esto reduce la carga en el backend y mejora la reactividad de la UI, pero requiere una higiene de datos más estricta.
Para empezar, un monolito modular suele ser lo más práctico:
A medida que crece el uso, lo primero que se suele separar es la ruta de evaluación (mucha lectura) del camino de administración (muchas escrituras). Puedes mantener el mismo modelo de datos mientras introduces un servicio de evaluación dedicado más adelante.
Los chequeos de flags ocurren en rutas críticas, así que optimiza las lecturas:
El objetivo es comportamiento consistente incluso durante caídas parciales: si el dashboard está caído, las aplicaciones deben evaluar usando la última configuración válida.
Un sistema de feature flags triunfa o fracasa por su modelo de datos. Si es demasiado laxo, no puedes auditar cambios ni hacer rollback con seguridad. Si es demasiado rígido, los equipos lo evitarán. Busca una estructura que soporte valores por defecto claros, targeting predecible y un historial fiable.
Flag es el interruptor a nivel de producto. Mantenlo estable en el tiempo dándole:
key (único, usado por SDKs, p. ej. new_checkout)name y description (para humanos)type (boolean, string, number, JSON)archived_at (eliminación suave)Variant representa el valor que una flag puede devolver. Incluso las flags booleanas se benefician de variantes explícitas (on/off) porque estandariza reporting y rollouts.
Environment separa el comportamiento por contexto: dev, staging, prod. Modelalo explícitamente para que una flag pueda tener reglas y defaults distintos por entorno.
Segment es una definición de grupo guardada (p. ej., “Beta testers”, “Usuarios internos”, “Grandes gastadores”). Los segmentos deben ser reutilizables en muchas flags.
Las reglas son donde vive la mayor parte de la complejidad, así que trátalas como registros de primera clase.
Un enfoque práctico:
FlagConfig (por flag + environment) almacena default_variant_id, estado enabled y un apuntador a la revisión publicada actual.Rule pertenece a una revisión e incluye:
priority (número: gana el menor)conditions (array JSON con comparaciones de atributos)serve (variante fija, o rollout porcentual entre variantes)fallback es siempre default_variant_id en FlagConfig cuando ninguna regla coincide.Esto mantiene la evaluación simple: carga la revisión publicada, ordena reglas por prioridad, aplica la primera que coincida, si no, default.
Trata cada cambio como una nueva FlagRevision:
status: draft o publishedcreated_by, created_at, comentario opcionalPublicar es una acción atómica: asignar FlagConfig.published_revision_id a la revisión elegida (por entorno). Los drafts permiten preparar cambios sin afectar a los usuarios.
Para auditoría y rollback, guarda un log append-only:
AuditEvent: quién cambió qué, cuándo y en qué entornobefore/after snapshots (o un patch JSON) referenciando los IDs de revisiónRollback se convierte en “re-publicar una revisión anterior” en lugar de reconstruir manualmente ajustes. Es más rápido, seguro y fácil de explicar a stakeholders no técnicos mediante la vista de historial del dashboard.
El targeting es la parte de “quién recibe qué” en las feature flags. Bien hecho, te permite entregar de forma segura: exponer un cambio a usuarios internos primero, luego a un nivel de cliente, luego a una región—sin redeploy.
Empieza con un conjunto pequeño y consistente de atributos que tus apps puedan enviar con cada evaluación:
Mantén los atributos simples y predecibles. Si una app envía plan=Pro y otra plan=pro, las reglas se comportarán de forma inesperada.
Los segmentos son grupos reutilizables como “Beta testers”, “Clientes EU” o “Admins enterprise”. Implémentalos como definiciones guardadas (no listas estáticas), para que la pertenencia se calcule al vuelo:
Para mantener la evaluación rápida, cachea resultados de pertenencia a segmentos por un corto tiempo (segundos/minutos), indexado por entorno y usuario.
Define un orden claro de evaluación para que los resultados sean explicables en el dashboard:
Soporta grupos AND/OR y operadores comunes: equals, not equals, contains, in list, greater/less than (para versiones o atributos numéricos).
Minimiza datos personales. Prefiere identificadores estables y no-PII (p. ej., un ID interno). Cuando debas almacenar identificadores para listas allow/deny, guarda IDs hasheados cuando sea posible y evita copiar emails, nombres o IPs sin procesar en el sistema de flags.
Los rollouts son donde un sistema de feature flags aporta valor real: puedes exponer cambios gradualmente, comparar opciones y detener problemas rápido—sin redeploy.
Un rollout porcentual significa “habilitar para el 5% de usuarios” y luego aumentar conforme crece la confianza. El detalle clave es la bucketización consistente: el mismo usuario debe permanecer dentro (o fuera) del rollout entre sesiones.
Usa un hash determinista de un identificador estable (por ejemplo, user_id o account_id) para asignar un bucket de 0–99. Si eliges usuarios al azar en cada solicitud, la gente “flipará” entre experiencias, las métricas se contaminarán y soporte no podrá reproducir problemas.
También decide la unidad de bucketización intencionalmente:
Empieza con flags booleanas (on/off), pero planifica variantes multivariantes (p. ej., control, new-checkout-a, new-checkout-b). Multivariantes son esenciales para A/B tests, experimentos de copy y cambios incrementales de UX.
Tus reglas deben devolver siempre un único valor resuelto por evaluación, con un orden de prioridad claro (p. ej., sobrescrituras explícitas > reglas de segmento > rollout porcentual > default).
La programación permite coordinar lanzamientos sin que alguien tenga que quedarse despierto para activar un switch. Soporta:
Trata los schedules como parte de la config de la flag para que los cambios sean auditables y previsualizables antes de hacerse efectivos.
Un kill switch es un “apagar” de emergencia que sobreescribe todo lo demás. Hazlo un control de primera clase con la ruta más rápida en UI y API.
Decide qué ocurre durante outages:
Documenta esto claramente para que los equipos sepan qué hará la app cuando el sistema de flags esté degradado. Para más sobre operaciones diarias, ver /blog/testing-deployment-and-governance.
Tu web app es solo la mitad del sistema. La otra mitad es cómo tu código de producto lee flags de forma segura y rápida. Una API limpia y un SDK pequeño por plataforma (Node, Python, móvil, etc.) mantiene la integración consistente y evita que cada equipo invente su propia solución.
Tus aplicaciones llamarán endpoints de lectura mucho más que de escritura, así que optimiza esos primero.
Patrones comunes:
GET /api/v1/environments/{env}/flags — lista todas las flags para un entorno (a menudo filtradas a “enabled” solamente)GET /api/v1/environments/{env}/flags/{key} — obtiene una sola flag por keyGET /api/v1/environments/{env}/bootstrap — obtiene flags + segmentos necesarios para evaluación localHaz que las respuestas sean cache-friendly (ETag o updated_at version), y mantén los payloads pequeños. Muchos equipos también soportan ?keys=a,b,c para fetch por lotes.
Los endpoints de escritura deben ser estrictos y predecibles:
POST /api/v1/flags — crear (validar unicidad de key, reglas de nombre)PUT /api/v1/flags/{id} — actualizar config en draft (validación de esquema)POST /api/v1/flags/{id}/publish — promover draft a un entornoPOST /api/v1/flags/{id}/rollback — revertir a la última versión conocida buenaDevuelve errores de validación claros para que el dashboard pueda explicar qué corregir.
Tu SDK debe manejar caché con TTL, reintentos/backoff, timeouts y fallback offline (servir últimos valores cacheados). También debe exponer una única llamada “evaluate” para que los equipos no necesiten entender tu modelo de datos.
Si las flags afectan precio, entitlements o seguridad, evita confiar en el cliente. Prefiere evaluación server-side, o usa tokens firmados (el servidor emite una “snapshot de flags” firmada que el cliente puede leer pero no falsificar).
Un sistema de feature flags solo funciona si la gente confía en él lo suficiente como para usarlo en lanzamientos reales. El dashboard es donde se construye esa confianza: etiquetas claras, defaults seguros y cambios fáciles de revisar.
Empieza con una vista simple de lista que soporte:
Haz que el “estado actual” sea legible de un vistazo. Por ejemplo, muestra On for 10%, Targeting: Beta segment o Off (kill switch activo) en vez de solo un punto verde.
El editor debe sentirse como un formulario guiado, no una pantalla técnica de configuración.
Incluye:
Si soportas variantes, muéstralas como opciones amigables (“New checkout”, “Old checkout”) y valida que el tráfico suma correctamente.
Los equipos necesitarán habilitar/deshabilitar en masa y “copiar reglas a otro entorno”. Añade salvaguardas:
Usa advertencias y notas obligatorias para acciones riesgosas (ediciones en Producción, saltos grandes de porcentaje, toggles de kill switch). Muestra un resumen de cambios antes de guardar—qué cambió, dónde y quién se verá afectado—para que revisores no técnicos puedan aprobar con confianza.
La seguridad es donde las herramientas de feature flags ganan confianza rápido—o se bloquean por el equipo de seguridad. Como las flags pueden cambiar experiencias de usuarios instantáneamente (y a veces romper producción), trata el control de acceso como parte central del producto.
Empieza con email + password por simplicidad, pero planea expectativas empresariales.
Un modelo limpio es control de acceso por roles (RBAC) más permisos por entorno.
Luego acota ese rol por entorno (Dev/Staging/Prod). Por ejemplo, alguien puede ser Editor en Staging pero solo Viewer en Prod. Esto previene flips accidentales en producción mientras mantiene a los equipos ágiles en otros entornos.
Añade un workflow de aprobación opcional para ediciones en producción:
Tus SDKs necesitarán credenciales para obtener valores de flags. Trátalas como API keys:
Para más sobre trazabilidad, conecta esta sección con el diseño del audit trail en /blog/auditing-monitoring-alerts.
Cuando las feature flags controlan experiencias reales de usuarios, “¿qué cambió?” se convierte en una cuestión de producción, no de papeleo. Auditoría y monitoreo convierten tu herramienta de rollouts en un sistema operativo en el que el equipo puede confiar.
Cada acción de escritura en la app admin debe emitir un evento de auditoría. Trátalo como append-only: nunca edites el historial—añade un nuevo evento.
Captura lo esencial:
Haz este log fácil de explorar: filtrar por flag, entorno, actor y rango de tiempo. Un “copiar link a este cambio” en deep link es invaluable en hilos de incidentes.
Añade telemetría ligera sobre evaluaciones de flags (lecturas del SDK) y resultados de decisión (qué variante se sirvió). Como mínimo, mide:
Esto ayuda tanto a depurar (“¿los usuarios realmente reciben la variante B?”) como a gobernanza (“¿qué flags están muertas y se pueden eliminar?”).
Las alertas deben conectar un evento de cambio con una señal de impacto. Una regla práctica: si una flag se habilitó (o se rampó) y los errores suben poco después, que alguien reciba un page.
Condiciones de alerta ejemplo:
Crea un área sencilla de “Ops” en tu dashboard:
Estas vistas reducen la incertidumbre durante incidentes y hacen que los rollouts se sientan controlados en vez de riesgosos.
Las feature flags están en la ruta crítica de cada petición, por lo que la fiabilidad es una característica de producto, no un detalle de infraestructura. Tu objetivo es simple: la evaluación debe ser rápida, predecible y segura incluso cuando partes del sistema están degradadas.
Empieza con caché en memoria dentro del SDK o servicio edge para que la mayoría de las evaluaciones nunca toquen la red. Mantén la caché pequeña y keyeada por entorno + versión del set de flags.
Añade Redis cuando necesites lecturas compartidas de baja latencia entre muchas instancias (y para reducir carga en la DB primaria). Redis también es útil para almacenar una “snapshot actual de flags” por entorno.
Un CDN ayuda solo cuando expones un endpoint de flags de solo lectura que sea seguro de cachear públicamente o por tenant (a menudo no lo es). Si usas CDN, prefiere respuestas firmadas y de corta vida y evita cachear datos específicos de usuario.
Polling es más simple: los SDKs obtienen la última snapshot cada N segundos con checks de ETag/version para evitar descargar datos sin cambios.
Streaming (SSE/WebSockets) ofrece propagación más rápida para rollouts y kill switches. Es ideal para equipos grandes, pero requiere más cuidado operativo (límites de conexiones, lógica de reconexión, fanout regional). Un compromiso práctico es polling por defecto con streaming opcional para entornos que necesitan “instantáneo”.
Protege tus APIs de una mala configuración del SDK (p. ej., polling cada 100ms). Impone intervalos mínimos por key de SDK en servidor y devuelve errores claros.
También protege tu base de datos: asegura que la ruta de lectura sea basada en snapshot, no en “evaluar reglas consultando tablas de usuarios”. La evaluación no debería disparar joins costosos.
Haz backups de la BD principal y realiza drills de restauración periódicamente (no solo backups). Almacena un historial inmutable de snapshots de flags para poder rollback rápido.
Define defaults seguros para outages: si no se puede contactar el servicio de flags, los SDKs deben volver a la última snapshot conocida; si no existe, por defecto “off” para features riesgosas y documenta excepciones (p. ej., flags críticas para billing).
Desplegar un sistema de feature flags no es “instalar y olvidar”. Como controla comportamiento en producción, necesitas alta confianza en la evaluación de reglas, flujos de cambio y caminos de rollback—y un proceso de gobernanza ligero para que la herramienta siga segura conforme más equipos la adopten.
Empieza con tests que protejan las promesas centrales:
Un consejo práctico: añade casos de prueba “golden” para reglas complejas (múltiples segmentos, fallbacks, condiciones en conflicto) para que las regresiones sean obvias.
Haz de staging un entorno de ensayo seguro:
Antes de releases a producción, usa un checklist breve:
Para gobernanza, mantenlo simple: define quién puede publicar a producción, exige aprobación para flags de alto impacto, revisa flags obsoletas mensualmente y añade un campo “fecha de expiración” para que rollouts temporales no vivan para siempre.
Si estás construyendo esto como plataforma interna, puede ayudar estandarizar cómo los equipos solicitan cambios. Algunas organizaciones usan Koder.ai para generar un dashboard inicial y luego iterar workflows (aprobaciones, resúmenes de auditoría, UX de rollback) con stakeholders en chat, y finalmente exportar el código para revisión de seguridad y ownership a largo plazo.
Una feature flag (toggle de características) es un control en tiempo de ejecución que activa una capacidad on/off (o a una variante) sin desplegar código nuevo. Separa entregar código de activar el comportamiento, lo que permite despliegues escalonados más seguros, rollback rápido y experimentos controlados.
Una configuración práctica separa:
Esta separación mantiene el flujo de cambios seguro y auditable mientras las evaluaciones son de baja latencia.
Usa bucketización consistente: calcula un hash determinista a partir de un identificador estable (por ejemplo, user_id o account_id), mapea a 0–99 y luego incluye/excluye según el porcentaje de rollout.
Evita la aleatoriedad por solicitud; si no, los usuarios “oscilarán” entre experiencias, las métricas quedarán ruidosas y soporte no podrá reproducir problemas.
Empieza con:
Un orden claro de precedencia hace los resultados explicables:
Mantén el conjunto de atributos pequeño y consistente (por ejemplo: role, plan, región, versión de la app) para evitar divergencias en las reglas entre servicios.
Almacena los horarios como parte de la configuración por entorno:
Haz que los cambios programados sean auditables y previsualizables para que los equipos confirmen qué ocurrirá antes de que esté en vivo.
Optimiza para uso intensivo de lectura:
Así evitas que tu base de datos sea consultada en cada chequeo de flag.
Si una flag afecta precios, derechos o comportamientos sensibles, prefiere evaluación server-side para que el cliente no pueda manipular reglas o atributos.
Si debes evaluar en cliente:
Usa RBAC más alcance por entorno:
Para producción, añade aprobaciones opcionales para cambios en targeting/rollouts/kill switch. Registra siempre solicitante, aprobador y el cambio exacto.
Como mínimo, captura:
Para fallos: los SDKs deben volver a la última config conocida, y luego a un valor por defecto seguro (a menudo “off” para features riesgosas). Ver también /blog/auditing-monitoring-alerts y /blog/testing-deployment-and-governance.
key estable, tipo, nombre/descripcion, archivado/eliminación suave.dev/staging/prod con configuraciones separadas.Añade revisiones (draft vs published) para que publicar sea un cambio atómico de pointer y el rollback sea “volver a publicar una revisión anterior”.