Enunciado y casos de uso
Diseñe un servicio de feature flags que permita a los equipos alternar funcionalidades sin volver a desplegar, admita segmentación por entorno, segmento de usuarios y porcentaje, y permanezca seguro cuando el servicio de configuración no esté disponible. Las preguntas de seguimiento pueden abarcar evaluación de baja latencia, auditabilidad, aprobaciones, reversión y disponibilidad multirregión.
Esto encaja en roles de ingeniería de plataformas, backend y diseño de sistemas. Las bibliotecas públicas de entrevistas describen enunciados similares con millones de evaluaciones por segundo y muy baja latencia; un informe publicado de entrevistas de ingeniería de plataformas enfatiza el plano de control, el plano de datos y el límite de despliegue seguro. Concéntrese en esas decisiones en lugar de nombrar componentes al azar.
Qué evalúa el entrevistador
- Si divide un sistema de configuración de pocas escrituras y muchas lecturas en planos de control y de datos.
- Si el despliegue porcentual es estable, de modo que un usuario no cambie de versión entre solicitudes.
- Si los valores predeterminados, la expiración, los kill switches y la reversión limitan el radio de impacto de una mala configuración.
- Si explica las compensaciones de consistencia, latencia, auditabilidad y aislamiento de inquilinos.
Aclaraciones antes de responder
Pregunte si la evaluación se ejecuta en un SDK, nodo perimetral o servicio central; si el objetivo es un millón de evaluaciones por segundo; si la segmentación utiliza usuarios, organizaciones, regiones o sesiones; con qué rapidez deben surtir efecto los cambios; y qué valor predeterminado seguro tiene cada flag. También aclare si se requieren experimentación, desactivación de emergencia y aprobaciones.
Una respuesta de 30 segundos
Definiría un plano de control para la creación de flags, reglas, versiones, aprobaciones y registros de auditoría, y luego un plano de datos donde los SDK o cachés perimetrales obtienen una instantánea publicada y evalúan localmente. Las reglas coinciden con el entorno y los segmentos objetivo; el despliegue porcentual utiliza un hash de sujeto estable. Libere gradualmente, supervise las alarmas y revierta automáticamente. Si el plano de control está caído, use una instantánea con desfase limitado o un valor predeterminado seguro adecuado al riesgo.
Solución paso a paso
Modelo de datos central
Un flag necesita un key, entorno, valor predeterminado, reglas ordenadas, versión, hora de publicación, expiración y metadatos de auditoría. Las reglas pueden dirigirse a organizaciones, regiones, atributos de usuario o un bucket de porcentaje. El orden de las reglas debe ser explícito: la primera coincidencia gana. Valide la sintaxis, los tipos y los conflictos semánticos antes de la publicación.
Plano de control y plano de datos
El plano de control maneja escrituras, aprobaciones, control de versiones, auditorías y publicación. El plano de datos solo lee instantáneas publicadas y las evalúa. Los SDK prefieren una caché en memoria y se actualizan mediante sondeo, un flujo o notificaciones. Por lo tanto, una interrupción breve del plano de control no impone una llamada de red en cada solicitud de negocio.
Despliegue estable y lanzamiento seguro
Aplique hash a flagKey + stableSubjectId + salt y asígnelo a los buckets 0 a 9999. A medida que la exposición crece del 1% al 5%, 25%, 50% y 100%, los usuarios ya admitidos se mantienen en la misma versión. Valide las reglas y dependencias antes del lanzamiento; supervise los errores, la latencia de cola y las métricas de negocio durante el lanzamiento. Revierta a la última versión verificada cuando se activen las alarmas.
~~~text evaluate(flag, context, snapshot): rules = snapshot[flag].rules[context.environment] for rule in rules: if matches(rule.targeting, context): if rule.percentage is absent: return rule.value bucket = hash(flag.key + context.stableSubject + rule.salt) % 10000 if bucket < rule.percentage * 100: return rule.value return snapshot[flag].safeDefault ~~~
Principales compensaciones
| Opción | Beneficio | Costo | Cuándo usar |
|---|---|---|---|
| Evaluación central | Una única fuente de reglas y actualizaciones rápidas | Dependencia de red por solicitud | Bajo rendimiento o consistencia estricta |
| Evaluación local en SDK | Baja latencia y aislamiento del plano de control | Distribución más compleja y almacenamiento seguro | Alto QPS con obsolescencia limitada |
| Evaluación perimetral | Respuesta local y resiliencia regional | Distribución e invalidación más difíciles | Tráfico global y aislamiento regional |
AWS AppConfig documenta versiones, entornos, estrategias de despliegue, validadores, segmentación gradual y reversión basada en alarmas. Eso respalda tratar el flujo de trabajo de lanzamiento como parte del sistema; no requiere copiar cada componente de AWS a otro producto.
Respuesta modelo
Dividiría el servicio en planos de control y de datos. El plano de control almacena definiciones de flags, reglas, versiones y registros de auditoría. Tras la validación y aprobación, produce una instantánea publicada inmutable. Los SDK o nodos perimetrales almacenan en caché esa instantánea y evalúan localmente, evitando una llamada al servicio central en cada solicitud.
El despliegue porcentual utiliza un identificador de sujeto estable, por lo que un usuario se mantiene en una versión a medida que la exposición aumenta del 1% al 25%. Cada flag tiene un valor predeterminado seguro y una política de expiración. Si una aplicación no puede actualizarse, usa la última instantánea no expirada o deshabilita el comportamiento riesgoso de acuerdo con la política del flag. Expanda gradualmente mientras supervisa la tasa de errores, la latencia P99 y las métricas de negocio, luego revierta automáticamente ante alarmas. Un kill switch de ruta corta puede proporcionar desactivación de emergencia, con costos explícitos de invalidación de caché, autorización y auditabilidad.
Errores comunes
- Llamar al servicio central de configuración en cada solicitud y convertirlo en un único punto de falla de latencia.
- Usar números aleatorios para la segmentación porcentual, haciendo que un mismo usuario cambie de versión entre solicitudes.
- Omitir datos de versión, expiración y auditoría, haciendo imposible explicar quién publicó qué y cuándo.
- Diseñar solo una API de encendido/apagado sin validación, reversión ni valores predeterminados seguros.
- Mezclar consistencia eventual, ventanas de obsolescencia de caché y desactivación de emergencia sin políticas de riesgo separadas.
Preguntas de seguimiento y respuestas
¿Cómo mantiene la experiencia del usuario consistente entre instancias?
Todas las instancias utilizan el mismo identificador de sujeto estable, clave de flag y sal (salt), y exponen la versión de la instantánea. Nunca asigne buckets basándose en un ID de solicitud aleatorio. Para tráfico anónimo, use un identificador de sesión persistente y establezca su tiempo de vida.
¿Qué sucede cuando el servicio de configuración está caído?
El plano de datos continúa sirviendo la última instantánea no expirada. Después de su TTL, sigue la política de riesgo del flag y devuelve un valor predeterminado seguro. Los SDK deben exponer la antigüedad de la instantánea, los fallos de actualización y la fuente de evaluación para que el comportamiento obsoleto sea visible.
¿Cómo desactiva una funcionalidad peligrosa?
Proporcione un kill switch protegido por permisos con una ruta más corta que el despliegue ordinario para flags de alto riesgo. Registre el operador, el motivo, la versión y el alcance afectado incluso durante una emergencia.
¿Cómo previene reglas de segmentación incorrectas?
Ejecute verificaciones de esquema, tipo, conflicto y cobertura antes de la publicación. Evalúe las reglas con fixtures fuera de línea para que cada objetivo llegue a una rama esperada. Pruebe primero los cambios de alto riesgo en un entorno de prueba pasivo (shadow) o muy pequeño.
¿Cómo maneja múltiples regiones?
Replique las instantáneas publicadas por región mientras mantiene las lecturas locales del plano de datos. Incluya la versión y la hora de publicación en cada instantánea, supervise el desfase de versiones regionales y alerte cuando una región no pueda actualizarse. Continúe usando la instantánea segura anterior durante la brecha.
¿Cuándo debería evitar las feature flags?
La configuración puramente estática, las migraciones únicas o las decisiones de autorización que requieren consistencia transaccional pueden no pertenecer a un sistema de flags. Si la cantidad de flags, la complejidad de las reglas y la deuda de expiración aumentan, asigne propietarios, fechas de vencimiento y métricas de limpieza para que las reglas en tiempo de ejecución no reemplacen la disciplina normal de lanzamientos.