¿Cómo diseñarías un sistema de feature flags (banderas de funcionalidad)?

Pregunta y cuándo utilizarla

Diseña un sistema multi-tenant de feature flags utilizado por 20,000 instancias de servidor distribuidas en 3 regiones. Debe almacenar 50,000 flags entre distintos proyectos, procesar 5 millones de evaluaciones in-process por segundo con menos de 1 milisegundo de latencia p99 agregada, propagar un cambio publicado en menos de 5 segundos en el p99 y seguir evaluando durante una caída de 15 minutos del plano de control. Debe soportar variaciones tipadas, segmentación (targeting), lanzamientos porcentuales deterministas, registros de auditoría, aprobaciones y un interruptor de apagado de emergencia.

Los números son supuestos para la entrevista, no benchmarks de producto. Asume que cada runtime se suscribe a un máximo de 500 flags relevantes, el tamaño promedio de una definición de flag serializada es de 2 KB, las escrituras en el plano de control alcanzan un pico de 100 por segundo y las reglas de evaluación del lado del servidor pueden contener atributos sensibles. La entrega a clientes y móviles, las estadísticas de experimentación y un servicio de configuración de propósito general son temas de seguimiento más que requisitos base.

Esta pregunta es ideal para entrevistas de backend senior, plataforma, infraestructura, ingeniería de release y diseño de sistemas. La lección reutilizable es que un sistema puede hacer que la ruta de gestión esté fuertemente gobernada mientras mantiene la ruta de solicitudes local y altamente disponible. Esa separación determina casi todas las decisiones posteriores.

Qué evalúa el entrevistador

La primera señal es si el candidato separa el despliegue (deployment) del lanzamiento (release) y el plano de control del plano de datos. Un panel de control y una base de datos gestionan las definiciones de los flags. Los SDK de la aplicación evalúan un conjunto de reglas versionado dentro del mismo proceso. Un RPC remoto para cada verificación de flag introduciría la indisponibilidad de la gestión y la latencia de red en cada solicitud del producto.

La segunda señal es la precisión semántica. La evaluación de un flag necesita una clave de flag, un entorno, un valor de reserva tipado (fallback) y un contexto de evaluación. Las reglas ordenadas, los objetivos explícitos, la asignación porcentual y la regla por defecto deben tener una precedencia determinista. "Asignar aleatoriamente la funcionalidad al 10% de las solicitudes" es incorrecto cuando un usuario debe recibir una experiencia estable entre diferentes solicitudes y regiones.

La tercera señal es el diseño ante fallas. El estado del último valor válido conocido (last-known-good) preserva la evaluación durante una caída del plano de control, pero también convierte la configuración obsoleta en un riesgo explícito. Una respuesta sólida define el comportamiento de inicio, la obsolescencia máxima aceptable, la recuperación de brechas (gap recovery), el rechazo de actualizaciones inválidas, el comportamiento de desactivación de emergencia y diferentes valores por defecto para un cambio cosmético frente a una ruta de escritura peligrosa.

La cuarta señal es la propiedad operativa. Las modificaciones de flags son cambios en producción. La autenticación, autorización, separación de entornos, concurrencia optimista, validación, políticas de aprobación, registros de auditoría inmutables, publicación por etapas, rollback, propiedad y retiro (retirement) deben formar parte del diseño.

Preguntas para clarificar antes de responder

• ¿Dónde se realiza la evaluación? Los SDK del lado del servidor pueden recibir el conjunto completo de reglas y evaluar localmente. Los clientes web y móviles no pueden recibir de forma segura reglas de segmentación sensibles, por lo que necesitan un modelo filtrado o evaluado remotamente.
• ¿Qué mide el objetivo de 5 segundos? Debe definirse desde una publicación exitosa hasta que el 99% de las instancias de servidor suscritas y saludables apliquen esa versión. Las instancias fuera de línea y los clientes fuera de la ventana de frescura soportada requieren semánticas independientes.
• ¿Cuál es el contrato de fallback? Si un SDK nunca ha cargado una instantánea (snapshot) válida, devuelve el valor por defecto tipado provisto por el código de la aplicación. Tras la inicialización, puede utilizar la versión last-known-good durante la ventana de obsolescencia acordada.
• ¿Debe permanecer el mismo sujeto en la misma cohorte? El lanzamiento porcentual requiere una clave de segmentación estable y entradas de hash deterministas. Las sesiones anónimas necesitan un identificador duradero si la estabilidad es importante.
• ¿Pueden las reglas contener datos sensibles? Es preferible utilizar ID de segmentos y atributos no sensibles. La entrega del lado del servidor puede transportar reglas protegidas; la entrega a navegadores no debe exponer secretos, listas de permitidos internas ni lógica de autorización.
• ¿Qué tan crítico es el interruptor de apagado de emergencia? Un SLO de propagación de cinco segundos es útil pero no instantáneo. Las operaciones verdaderamente destructivas aún necesitan autorización del lado del servidor y controles de seguridad independientes.

Marco de respuesta en 30 segundos

"Dividiría la plataforma en un plano de control gobernado y un plano de evaluación local. El plano de control valida, versiona, audita y publica instantáneas y parches inmutables. Los SDK del servidor mantienen las últimas reglas válidas y evalúan objetivos, reglas ordenadas, lanzamientos y valores por defecto dentro del proceso; antes de la inicialización o ante un estado inválido, devuelven el fallback del código. Un lanzamiento determinista aplica una función hash a una clave de sujeto estable junto con el entorno, la clave del flag y una sal (salt). Los flujos de datos (streams) envían actualizaciones y el sondeo (polling) repara brechas, de modo que una caída del plano de control nunca impacta la ruta de solicitudes. Probaría la propagación, resultados consistentes entre SDK, estabilidad de cohortes, comportamiento con datos obsoletos y rollback bajo fallas."

Solución paso a paso

Paso 1: Convertir los requisitos en contratos explícitos

Los requisitos funcionales son crear, editar, aprobar, publicar, desactivar y retirar flags; definir variaciones booleanas, de texto, numéricas o estructuradas; segmentar sujetos o grupos; asignar porcentajes; y devolver detalles de evaluación para depuración. Los requisitos no funcionales son latencia local p99 menor a 1 milisegundo, propagación p99 de 5 segundos, resultados deterministas entre regiones y evaluación continua durante una caída de 15 minutos de la gestión.

Define tres límites antes de diagramar componentes:

1. Una versión publicada es inmutable. Una edición posterior genera otro borrador y otra versión.
2. El SLO de propagación aplica a instancias de servidor saludables y conectadas, no a dispositivos fuera de línea.
3. La aplicación es dueña del valor final de fallback. La plataforma nunca inventa un valor cuando falla la verificación de tipos, la inicialización o la evaluación.

Para el diseño base, el estado last-known-good permanece válido durante al menos los 15 minutos requeridos. Tras superar el límite stale_after publicado de un flag, su stale_action selecciona continuar evaluando con el last-known-good o recurrir al fallback del código, y el SDK devuelve una razón de obsolescencia. Una ruta crítica para la seguridad o destructiva debe elegir el fallback en lugar de aplicar silenciosamente una regla de habilitación antigua.

Esto evita ocultar políticas de producto dentro de la infraestructura. Una migración de checkout puede recurrir por defecto a la ruta antigua, mientras que una capacidad sensible a nivel de seguridad puede configurarse por defecto como deshabilitada. Ambas usan la misma plataforma con diferentes contratos de aplicación.

Paso 2: Separar el plano de control y el plano de datos de evaluación

El plano de control contiene la API y UI de gestión, verificaciones de identidad y roles, validador de esquemas y reglas, flujo de trabajo de aprobación, fuente de verdad relacional, registro de auditoría de solo adición (append-only), generador de instantáneas y publicador. Las escrituras tienen un volumen bajo en comparación con las evaluaciones, por lo que la corrección, la capacidad de revisión y la recuperabilidad importan más que la latencia en microsegundos.

El plano de datos contiene repetidores de flujo (stream relays) regionales, almacenamiento de instantáneas, endpoints de polling y almacenes y evaluadores locales en el SDK. Los SDK del servidor abren un stream regional, instalan una instantánea inmutable, aplican parches versionados y evalúan sin realizar llamadas de red. Si el stream se interrumpe, conservan el último estado válido y realizan polling con variación aleatoria (jitter). Si un parche omite una versión o falla la validación de checksum, el SDK descarta el parche y solicita una instantánea completa.

Mantén la entrega del plano de datos independiente de la base de datos principal de control. El publicador escribe un artefacto versionado duradero antes de notificar a los repetidores. Así, una caída de la base de datos o del panel de control puede impedir nuevas ediciones sin interrumpir las evaluaciones existentes.

Paso 3: Definir el modelo de datos y las API

Una definición de flag necesita al menos:

FlagDefinition {
  tenant_id, project_id, environment, flag_key
  version, value_type, variations[], off_variation
  ordered_rules[], default_rule, salt
  stale_after, stale_action
  state, owner, expires_at
}

Rule {
  rule_id, conditions[], outcome
}

Outcome = fixed_variation | weighted_variations[]

Los segmentos se versionan por separado porque muchos flags pueden hacer referencia a una misma cohorte. Una entrada de auditoría registra el autor, la hora, el motivo, la versión previa esperada, las referencias antes y después, la aprobación y el resultado de publicación. Mantén los borradores separados de los artefactos publicados para que una edición no aprobada no se filtre a la evaluación.

Las API representativas son:

PUT  /v1/projects/{project}/environments/{env}/flags/{key}
     body: draft definition, expectedVersion

POST /v1/projects/{project}/environments/{env}/flags/{key}:publish
     body: draftVersion, reason, approvalToken

GET  /v1/sdk/bootstrap?project={project}&env={env}&after={version}
GET  /v1/sdk/stream?project={project}&env={env}

La versión esperada evita que dos editores se sobrescriban mutuamente de forma silenciosa. Las credenciales de gestión nunca se utilizan como credenciales de SDK. El tenant, proyecto, entorno y modo de entrega permitido forman parte de cada decisión de autorización.

Paso 4: Hacer deterministas la evaluación y el lanzamiento porcentual

Utiliza un único orden documentado en todos los SDK:

1. Verificar la existencia del flag, entorno, tipo y si la segmentación está habilitada.
2. Aplicar un objetivo explícito de sujeto o segmento.
3. Evaluar reglas ordenadas; la primera regla que coincida gana.
4. Resolver una variación fija o un lanzamiento ponderado.
5. Utilizar la regla por defecto cuando nada coincida.
6. Devolver el fallback de la aplicación con una razón de error cuando la evaluación no pueda producir un resultado tipado válido.

Para un lanzamiento ponderado, calcula un bucket a partir de entradas estables:

bucket = H(tenant_id || environment || flag_key || salt || targeting_key) mod 100000

Mapea el bucket en rangos acumulativos de variación. Las mismas entradas producen el mismo resultado en cada instancia y región. Mantener la sal y la versión del algoritmo en la definición publicada hace que el comportamiento sea reproducible. Expandir un rango contiguo existente puede preservar a los sujetos que ya están dentro de él, pero reajustar los pesos arbitrariamente o cambiar las entradas del hash puede mover a los usuarios de grupo; expón esa consecuencia durante la revisión.

Dos flags independientes con los mismos porcentajes no necesariamente seleccionan a los mismos sujetos porque la clave del flag participa en la función hash. Si varios flags deben moverse como una sola cohorte, apunta a un segmento versionado compartido o utiliza una clave de experimento explícita. Nunca uses campos mutables como el correo electrónico en el hash si existe un ID de sujeto estable.

Paso 5: Entregar instantáneas y cambios incrementales de forma segura

El generador de instantáneas resuelve el alcance del proyecto y entorno, valida segmentos referenciados y prerrequisitos, ordena las reglas de manera determinista, serializa un artefacto canónico y adjunta una versión y checksum. Una transacción confirma los metadatos publicados y un registro de outbox; un publicador asíncrono almacena el artefacto y lo anuncia a los repetidores regionales. Esto evita confirmar un flag sin programar su entrega.

La secuencia de arranque de un SDK es:

1. Cargar una instantánea last-known-good persistente y válida cuando esté configurada.
2. Obtener el artefacto completo o incremental más reciente del repetidor más cercano.
3. Reemplazar atómicamente la instantánea en memoria solo después de verificar el tipo, versión y checksum.
4. Marcar el proveedor como listo y comenzar a atender evaluaciones locales.
5. Mantener un stream abierto para actualizaciones y usar polling como ruta de reparación.

Nunca mutes el conjunto de reglas activo en memoria directamente. Construye una nueva instantánea inmutable y cambia una sola referencia para que las solicitudes concurrentes vean o bien la versión antigua completa, o bien la nueva versión completa. Registra la versión aplicada y la razón de evaluación en los detalles de diagnóstico.

Paso 6: Diseñar la semántica de fallas antes del camino feliz

El interruptor de apagado de emergencia utiliza la misma ruta de publicación duradera con un canal de prioridad, no un canal secundario mutable y sin auditar. Puede omitir la espera ordinaria de aprobación solo bajo una política de "break-glass" preautorizada, pero aun así registra el autor, motivo, versión previa y resultado. Un objetivo de propagación de cinco segundos no puede garantizar que cada instancia desconectada haya cambiado; las acciones destructivas requieren validación independiente.

Paso 7: Proteger la plataforma para evitar que la configuración se convierta en autoridad

Separa los roles de gestión por tenant, proyecto y entorno. Las ediciones en producción pueden requerir un segundo aprobador, mientras que las de desarrollo pueden publicarse directamente. Cifra credenciales, rota claves de SDK, limita la tasa de llamadas de gestión y asegura que una clave de servidor no pueda editar flags. Un registro de auditoría append-only y artefactos inmutables hacen posible la reconstrucción de incidentes.

Trata la entrega a clientes de forma diferente a la entrega a servidores. Envía a navegadores o dispositivos móviles únicamente los flags aprobados explícitamente para exposición a clientes y, preferiblemente, envía valores ya evaluados para su contexto. Un usuario puede inspeccionar o modificar el estado del cliente, por lo que un flag puede alterar la presentación pero no puede otorgar autorización, eludir pagos ni reemplazar una verificación de permisos del lado del servidor. Minimiza los campos de identificación personal en el contexto de evaluación y seudonimiza los identificadores de telemetría.

Asigna a cada flag temporal de lanzamiento un propietario y una condición de retiro. Una vez completado el lanzamiento, primero haz permanente la ruta ganadora, luego deja de evaluar el flag y finalmente elimina la definición después de que las referencias en el código desaparezcan. De lo contrario, las bifurcaciones antiguas y los flags interactuando entre sí expanden la matriz de pruebas indefinidamente.

Paso 8: Recalcular la capacidad y validar el diseño

Con 500 flags suscritos con un promedio de 2 KB, una instantánea en runtime es de aproximadamente 1 MB. Inicializar 20,000 instancias a la vez transfiere cerca de 20 GB antes del protocolo y la sobrecarga de replicación. Coloca los artefactos canónicos detrás de repetidores regionales o entrega por objetos, usa versiones condicionales, aplica jitter en las reconexiones y limita la concurrencia de inicialización. Un solo cambio de 2 KB distribuido a 20,000 instancias representa unos 40 MB de carga útil lógica, por lo que la entrega incremental es mucho más económica que una actualización completa.

Cinco millones de evaluaciones por segundo no deben emitir sincrónicamente cinco millones de eventos de red. Incluso un evento de 200 bytes representaría alrededor de 1 GB por segundo, u 86.4 TB por día antes de la replicación. Agrupa en búfer, procesa por lotes, muestrea o agrega los diagnósticos ordinarios. Conserva eventos completos de asignación solo cuando el contrato de un experimento lo requiera, y coloca la telemetría en una cola acotada que pueda descartar eventos no críticos sin retrasar la evaluación.

La validación abarca más que el rendimiento:

• Ejecuta las mismas reglas de prueba (golden rules) y contextos contra cada implementación de SDK y compara el valor, variante, razón y comportamiento de errores.
• Realiza pruebas basadas en propiedades (property tests) para el determinismo de buckets, la distribución aproximada y la estabilidad al expandir un rango de lanzamiento existente.
• Mide el p50 y p99 local según la cantidad de reglas y el tamaño del segmento; mide el retraso entre publicación y aplicación por separado.
• Desconecta streams, detén la base de datos de control, corrompe un parche, omite una versión, expira credenciales y reinicia todas las instancias simultáneamente.
• Publica una regla defectuosa en una pequeña cohorte canary, activa una alarma de salud y verifica que el rollback cree y propague una nueva versión auditada.
• Verifica el aislamiento de tenants, la aprobación en producción, el filtrado de exposición a clientes, la completitud de auditoría y el retiro de flags.

Ejemplo de una respuesta sólida

"Limitaré el alcance del sistema base a la evaluación del lado del servidor. Hay 20,000 instancias en tres regiones, pero solo 100 escrituras de control por segundo, por lo que ambas rutas de tráfico no deben compartir una dependencia de disponibilidad. El servicio de gestión almacena borradores y versiones publicadas inmutables en una base de datos relacional. Cada publicación valida tipos, referencias a reglas y permisos, comprueba la versión previa esperada, escribe un registro de auditoría y una entrada de outbox, y luego construye un artefacto canónico para el proyecto y entorno.

Los repetidores regionales distribuyen ese artefacto. Cada SDK carga una instantánea last-known-good, recibe actualizaciones mediante un stream y sondea periódicamente para reparar brechas. Instala una nueva instantánea inmutable de forma atómica y evalúa localmente, manteniendo la latencia de las solicitudes por debajo del objetivo p99 de 1 milisegundo, incluso cuando el plano de control está caído. El estado last-known-good es válido durante al menos 15 minutos; tras el límite de obsolescencia publicado, el flag mantiene ese valor o utiliza el fallback tipado del código según su política de riesgo. La versión local, la frescura y la razón de evaluación son observables.

El orden de evaluación es: estado desactivado, objetivos explícitos, reglas ordenadas, resultado ponderado y valor por defecto. El lanzamiento porcentual aplica hash al tenant, entorno, flag, sal y una clave de segmentación estable en 100,000 buckets, asegurando que cada instancia tome la misma decisión. Cambiar las entradas del hash se considera una migración; múltiples flags que requieran la misma cohorte usan un segmento compartido en lugar de porcentajes casualmente iguales.

El mayor pico ocurre durante el arranque de la flota: una instantánea delimitada de 1 MB multiplicada por 20,000 instancias representa unos 20 GB. Serviría las instantáneas regionalmente, enviaría deltas, aplicaría jitter a las reconexiones y limitaría los reintentos. La telemetría de evaluación se procesa por lotes y se muestrea, ya que registrar 5 millones de eventos sincrónicos por segundo pondría en riesgo la ruta crítica del producto. Finalmente, probaría la conformidad entre SDK, el p99 de propagación, tormentas de reinicio, operación con datos obsoletos, versiones corruptas y faltantes, rollback en canary, auditoría de break-glass, aislamiento de tenants y exposición a clientes. El sistema tiene éxito cuando la evaluación de solicitudes permanece local y determinista mientras cada cambio de configuración se mantiene gobernado y recuperable."

Errores comunes

• Llamar a un servicio central para cada evaluación → la latencia y disponibilidad del producto pasan a depender del servicio de flags → enviar reglas versionadas a los SDK del servidor y evaluar in-process.
• Seleccionar usuarios aleatoriamente en cada solicitud → un mismo usuario salta entre variantes y los datos del experimento se contaminan → aplicar hash a una clave de segmentación estable con entradas documentadas y específicas del flag.
• Tratar el last-known-good como permanentemente correcto → una instancia desconectada puede servir indefinidamente una regla obsoleta e insegura → definir observabilidad de obsolescencia, comportamiento de reconexión y reparación, y un fallback seguro a nivel de aplicación.
• Enviar el conjunto de reglas del servidor a un navegador → los usuarios pueden inspeccionar segmentos sensibles y credenciales → filtrar flags seguros para clientes o evaluar remotamente, y aplicar la autorización en el servidor.
• Actualizar un objeto de reglas compartido directamente en memoria → solicitudes concurrentes pueden observar una configuración aplicada parcialmente → validar una instantánea inmutable completa y cambiar las referencias de forma atómica.
• Registrar cada evaluación de forma sincrónica → la telemetría se convierte en la dependencia de mayor volumen en la ruta de solicitudes → agrupar en lotes, muestrear, agregar y descartar eventos no críticos.
• Realizar cambios de emergencia sin auditoría → la vía de recuperación más rápida se convierte en una puerta trasera de producción no rastreable → utilizar un canal de publicación prioritario con política de break-glass preautorizada y auditoría inmutable.
• Nunca retirar flags → las ramas obsoletas y las interacciones entre flags multiplican el costo de pruebas → asignar un propietario y eliminar la definición tras hacer permanente la ruta de código ganadora.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Cómo soportarías SDK para navegadores y dispositivos móviles?

No entregues el conjunto de reglas completo del servidor. Marca qué flags son aptos para clientes, autentica la aplicación en lugar de confiarle credenciales de gestión y devuelve valores filtrados o resultados evaluados específicos para su contexto. Almacena en caché los valores para uso sin conexión con una versión visible y estado de frescura. Un flag de cliente sigue siendo una sugerencia de experiencia de usuario; el servidor verifica de forma independiente permisos, compras, cuotas y otras decisiones de seguridad.

Pregunta de seguimiento 2: ¿Cómo logran varios flags mantener exactamente la misma cohorte de lanzamiento?

Los porcentajes idénticos son insuficientes porque cada clave de flag altera la entrada de la función hash. Crea un segmento compartido y versionado, o una asignación de experimento identificada por un ID de experimento común, y luego haz referencia a él desde cada flag. Publica de manera consistente las versiones de segmentos y flags dependientes, y prueba que la pertenencia a la cohorte permanezca estable antes de incrementar la exposición.

Pregunta de seguimiento 3: ¿Qué pasa si un segmento tiene diez millones de miembros?

No incluyas la lista completa de miembros en cada instantánea. Representa la pertenencia como un artefacto versionado compacto, divídelo en shards según el hash del sujeto o precalcula un atributo que el evaluador pueda consumir. Los filtros de Bloom pueden reducir el tráfico de búsquedas negativas, pero no pueden ser el único mecanismo de autorización debido a la existencia de falsos positivos. Mide el consumo de memoria, la latencia de búsqueda, la amplificación de actualizaciones y la membresía obsoleta por separado de las reglas ordinarias.

Pregunta de seguimiento 4: ¿Puede un interruptor de apagado de emergencia ser instantáneo?

Ninguna publicación distribuida alcanza a procesos desconectados de forma instantánea. Otorga prioridad a los cambios de emergencia, mantén activos los streams regionales, mide las confirmaciones de recepción (acknowledgments) y genera alertas ante versiones retrasadas. Para una operación destructiva, combina el flag con una protección impuesta por el servidor, como deshabilitar el endpoint de escritura, revocar una capacidad o bloquear solicitudes en el gateway. El flag mejora la velocidad de recuperación pero no reemplaza un límite de seguridad estricto.

Pregunta de seguimiento 5: ¿Cómo migrarías el algoritmo de hash?

Almacena la versión del algoritmo y la sal junto con cada flag publicado. Ejecuta los evaluadores antiguo y nuevo en modo sombra (shadow mode) y mide el desplazamiento de asignaciones. Si el movimiento es aceptable, publica una migración por etapas; de lo contrario, preserva las asignaciones existentes de los sujetos en un segmento o tabla de migración hasta que concluya el lanzamiento. Nunca cambies la implementación de hash del SDK de manera silenciosa, ya que diferentes versiones entrarían en conflicto.

Pregunta de seguimiento 6: ¿Cómo evitas un ciclo de dependencias entre flags?

Construye el grafo de prerrequisitos durante la publicación y rechaza una versión si el recorrido en profundidad (DFS) detecta un ciclo. Limita la profundidad máxima de prerrequisitos y el trabajo total de evaluación para que un grafo acíclico pero patológico no viole la latencia. Incluye las versiones de los flags referenciados en el artefacto, prueba el orden de evaluación entre los distintos SDK y expón la cadena de dependencias en los detalles de diagnóstico.