Planteamiento y contexto
Esta pregunta aísla la ruta crítica de evaluación de feature flags. La administración, las aprobaciones y la plataforma en general pertenecen a un problema de diseño independiente. La configuración se propaga de forma asíncrona y los clientes utilizan SDKs en varios lenguajes; aun así, un usuario debe recibir una variante explicable y reproducible. Asuma una evaluación en el lado del servidor y dentro del proceso, con reglas de atributos y despliegues porcentuales.
Qué evalúa el entrevistador
- Separar la convergencia eventual de la configuración del bucketing estable para una misma identidad.
- Definir un único
targetingKey, contrato de normalización y algoritmo de hash entre SDKs. - Alternar instantáneas (snapshots) inmutables y con versiones monótonas en lugar de exponer actualizaciones parciales.
- Devolver un valor predeterminado seguro ante falta de contexto, errores de tipo, flags desconocidos y configuraciones obsoletas.
- Demostrar la consistencia mediante vectores de prueba canónicos (golden vectors), evaluación en modo sombra (shadow evaluation) y métricas de distribución.
Aclaraciones antes de responder
Pregunte si la estabilidad debe mantenerse entre dispositivos, regiones y lenguajes de SDK; cómo persisten las identidades anónimas; y si los usuarios que ya están dentro de un despliegue del 10% deben permanecer incluidos cuando este aumente. También determine qué atributos de segmentación son confidenciales, la ventana de propagación tolerada y si un interruptor de apagado de emergencia invalida las reglas habituales de despliegue.
Estructura para una respuesta de 30 segundos
Compilaría las reglas en instantáneas inmutables y versionadas, y las evaluaría dentro de cada SDK. La asignación porcentual codifica targetingKey, flagKey y la semilla como una tupla canónica con longitud prefijada antes de aplicar el hash en rangos fijos. Para un cambio ordinario, se distribuye una instantánea inactiva, se espera a que cada región de servicio reporte que está lista y luego se avanza una generación de asignación en el plano de control. Cada sesión o identidad duradera transporta esa generación, y las instancias de servicio retienen ambas instantáneas durante un solapamiento acotado, de modo que el desfase de reloj local no pueda mover a un usuario entre versiones de reglas. Si falta contexto, los tipos de regla son inválidos o la configuración está obsoleta, se devuelve el valor predeterminado del llamador con un código de motivo. Los vectores de prueba canónicos multilenguaje y la evaluación en sombra verifican que las decisiones sean idénticas.
Análisis detallado paso a paso
Comience con el contrato de entrada. Cada evaluación en el servidor necesita un targetingKey no vacío. El tráfico anónimo puede utilizar un identificador aleatorio persistido, pero no un valor nuevo por cada solicitud. Especifique la codificación de cadenas, mayúsculas/minúsculas, espacios en blanco, números y normalización de marcas de tiempo. Aplique el hash a una tupla UTF-8 versionada y con longitud prefijada en lugar de una concatenación simple o delimitadores únicamente; de lo contrario, los límites de los campos y los caracteres delimitadores seguirán siendo ambiguos entre los SDKs.
Una función de bucket puede ser bucket = hash(encodeTuple(v, seed, flagKey, targetingKey)) mod 100000. Cada variante posee un rango contiguo que no se solapa. Pasar del 10% al 20% expande el rango objetivo, conservando a los usuarios originales. Incluir flagKey evita que flags no relacionados seleccionen muestras perfectamente correlacionadas. Cambiar la semilla redistribuye deliberadamente a los usuarios y, por lo tanto, requiere un lanzamiento auditado.
La coincidencia de reglas y el bucketing deben ver una única instantánea inmutable. El distribuidor envía a cada región de servicio una instantánea inactiva completa con suma de comprobación y versión monótona. Después de que todas las regiones validan y confirman que están listas, el plano de control avanza una generación de asignación autoritativa. Un token de sesión o registro de identidad duradera transporta esa generación; cada región evalúa exactamente la instantánea referenciada y conserva la instantánea anterior hasta que expire el tiempo de vida de la asignación. Las instancias a las que les falte la versión referenciada dejan de atender esa asignación. Este protocolo se basa en el transporte de versiones en lugar de relojes sincronizados. Un interruptor de corte de emergencia puede anular explícitamente la persistencia por seguridad sin dejar de ser una regla versionada y registrada.
El contrato de evaluación de OpenFeature permite a los llamadores suministrar un valor predeterminado y asocia motivos de error con las evaluaciones fallidas. Distinga entre flags faltantes, discrepancias de tipo, claves de segmentación ausentes y un proveedor que no esté listo. Mantenga las métricas con baja cardinalidad y no incluya direcciones de correo electrónico, identificadores de dispositivos ni el contexto de evaluación completo en los registros rutinarios.
La verificación tiene tres capas. Cada SDK ejecuta las mismas entradas canónicas y variantes esperadas, incluidos valores vacíos, delimitadores, Unicode y casos de colisión en límites de campo. Antes de reemplazar un evaluador, evalúe en sombra ambos motores con instantáneas representativas de producción y ensaye un escenario donde una región no reporte estar lista. En producción, supervise la cuota de variantes, la tasa de valores predeterminados, la antigüedad de las instantáneas y la distribución de versiones por región. Una anomalía en la distribución es una señal; una decisión individual aún debe ser reproducible a partir de la versión de la instantánea, el ID de la regla y el bucket.
Ejemplo de respuesta sólida
Cada SDK evalúa únicamente una instantánea validada. La solicitud proporciona un targetingKey estable; el SDK aplica una función hash a una tupla versionada y con longitud delimitada de seed, flagKey y targetingKey en uno de 100.000 buckets fijos. Aumentar la exposición solo amplía el rango, por lo que los miembros existentes no quedan fuera.
Los cambios ordinarios llegan a todas las regiones antes de que el plano de control avance la generación de asignación. La sesión o la identidad duradera transporta entonces esa generación, y cada región conserva la instantánea referenciada durante la vida útil de la asignación. Por lo tanto, las solicitudes entre regiones evalúan una única versión de regla sin depender de relojes sincronizados. Las instancias a las que les falte esa instantánea dejan de atender la asignación. Los SDKs rechazan regresiones y devuelven el valor predeterminado del llamador ante una configuración obsoleta o un contexto inválido. El apagado de emergencia anula explícitamente la persistencia ordinaria y converge primero.
Errores comunes
- Llamar a un servicio remoto de flags para cada evaluación y acoplar la disponibilidad de la solicitud a este.
- Usar la función de hash integrada del entorno de ejecución de un lenguaje, que puede diferir entre procesos o SDKs.
- Aplicar hash solo al ID de usuario, generando muestras correlacionadas en todos los flags.
- Actualizar la configuración campo por campo, exponiendo versiones mixtas de reglas y ponderaciones.
- Asignar solicitudes al azar cuando falta
targetingKey. - Registrar el contexto de evaluación completo y filtrar atributos confidenciales.
Preguntas de seguimiento
¿Pueden ser consistentes globalmente diferentes versiones de configuración?
La distribución asíncrona por sí sola no puede prometer una ventana de consistencia global de ancho cero. Un cambio ordinario primero supera la validación de preparación en cada región de servicio; luego, el plano de control avanza una generación de asignación, que la sesión o la identidad duradera transporta en cada solicitud. Las regiones retienen la instantánea referenciada hasta que expire esa asignación, y una instancia a la que le falte abandona la ruta de servicio. Un interruptor de apagado de emergencia puede anular la persistencia, priorizar una convergencia rápida y supervisar las instancias rezagadas.
¿Qué debería identificar a un usuario anónimo?
Utilice un ID anónimo aleatorio persistido en el cliente y documente que borrar el almacenamiento o cambiar de dispositivo provoca una reasignación. Las direcciones IP son compartidas, inestables y conllevan problemas de privacidad adicionales.
¿Cómo se cambia el algoritmo de hash de forma segura?
Ponga versión al algoritmo y a la semilla en la instantánea, y luego calcule en sombra los buckets antiguos y nuevos para medir el desplazamiento. Conserve las asignaciones mediante un mapeo de transición cuando se requiera persistencia. Si la redistribución es aceptable, láncela de forma explícita con una instantánea de reversión.
¿Cómo se detecta una implementación de SDK defectuosa?
Ejecute vectores canónicos idénticos en cada SDK y reporte la versión del algoritmo con baja cardinalidad, la versión de la instantánea y los recuentos agregados de variantes. Congele las actualizaciones de configuración para el SDK divergente, retenga su última instantánea válida y corrija la normalización o el hash antes de reanudar.