Planteamiento y contexto
La plataforma sirve feature flags booleanas, de cadena de texto y estructuradas a servicios multiinquilino (multi-tenant). Las reglas pueden depender del inquilino, usuario, región y versión de la aplicación. Tras un despliegue, algunas instancias se actualizan de inmediato mientras que otras sufren retrasos de minutos, y el contexto sensible no debe llegar a los registros. Diseña el plano de control, el plano de datos, el contexto de evaluación, la caché, el despliegue, los fallos y el ciclo de auditoría.
Qué está evaluando el entrevistador
- Separar la publicación del plano de control de la evaluación del plano de datos y definir objetivos de versión y consistencia.
- Fusionar, sobrescribir, propagar y proteger correctamente el contexto de evaluación.
- Diseñar la invalidación de caché, instantáneas sin conexión, valores predeterminados y rollbacks sin requerir una RPC en vivo por cada solicitud.
- Hacer que la telemetría de exposición, errores, cambios y coincidencias de reglas sea auditable sin filtrar datos personales.
Preguntas para aclarar primero
- ¿La evaluación debe ser fuertemente consistente o se aceptan datos desactualizados (stale)? ¿Cuál es la obsolescencia máxima permitida?
- ¿Cuál es la precedencia de reglas para inquilino, usuario, dispositivo, región y versión?
- ¿Cuánto tiempo deben operar los servicios cuando el plano de control no esté disponible y quién aprueba los valores predeterminados?
- ¿Qué campos de contexto constituyen datos personales y cuáles pueden incluirse en los registros de exposición?
- ¿Se requieren SDKs multilenguaje y evaluación local sin conexión, o es aceptable un evaluador remoto?
Estructura de respuesta en 30 segundos
El plano de control validaría las reglas, publicaría versiones inmutables, gestionaría aprobaciones y ejecutaría rollbacks. Los SDKs del plano de datos evaluarían instantáneas locales versionadas para garantizar baja latencia y funcionamiento sin conexión. El contexto fusionaría los ámbitos global, de transacción y de invocación con un orden explícito de sobrescritura y campos mínimos. Las instancias recibirían actualizaciones mediante transmisión en tiempo real (streaming) combinada con sondeo (polling), con TTL y una verificación de monotonicidad de versiones. Los fallos utilizarían un valor predeterminado tipado o el último valor válido conocido (last-known-good) e indicarían la obsolescencia; las flags críticas podrían fallar de forma cerrada (fail closed). Los eventos de auditoría contendrían versiones y claves anónimas, nunca atributos en bruto.
Respuesta detallada paso a paso
Paso 1: Definir objetos y una máquina de estados de publicación
Una flag contiene tipo, valor predeterminado, reglas, variantes, entorno, versión y hora de activación. La publicación avanza por borrador, validación, aprobación, despliegue canary, completado o rollback; cada cambio genera una versión inmutable. Los errores de compilación, las discrepancias de tipos o la falta de valores predeterminados bloquean la publicación en lugar de convertirse en fallos en tiempo de ejecución para cada servicio.
Paso 2: Diseñar el contexto de evaluación
Representa los atributos de aplicación, host, región, inquilino y usuario como contexto estructurado. Fusiona el contexto global, de transacción y de invocación según la especificación con un orden explícito para claves duplicadas. Los SDKs no deben leer implícitamente estados de hilo arbitrarios. Aplica listas de permitidos (allowlists) de campos y anonimización antes de que el contexto entre a un SDK, transporte o registro.
Paso 3: Elegir evaluación local o remota
La baja latencia y la tolerancia a caídas breves del plano de control favorecen la evaluación local a partir de una instantánea distribuida de reglas. La evaluación remota centraliza la lógica compleja, pero añade dependencia de red y disponibilidad a cada llamada. Un enfoque híbrido puede mantener la evaluación simple en el SDK y recurrir a un proveedor para reglas complejas, devolviendo valores tipados, motivos, versiones y metadatos.
Paso 4: Establecer objetivos de caché y consistencia
Indexa las cachés de instantáneas por entorno, conjunto de flags y versión, protegiéndolas con sumas de verificación (checksums) y caducidad. El sondeo compensa las notificaciones de actualización perdidas. Una instancia inicia desde su última instantánea confiable y se pone al día de forma asíncrona. Define como SLOs las reglas de “nunca retroceder”, segundos máximos de obsolescencia y tiempo de propagación de rollbacks.
Paso 5: Gestionar fallos y valores predeterminados seguros
Ante errores de evaluación, devuelve un valor predeterminado compatible con el tipo o el último valor válido conocido junto con el motivo, código de error y origen. Las flags de pagos, autorización y eliminación no deben adoptar silenciosamente un valor predeterminado peligroso; pueden bloquearse o utilizar una política aprobada de fallo cerrado (fail-closed). Protégete contra flags desconocidas, conversiones de tipos no seguras y tiempos de espera (timeouts) de reglas que se propaguen a los llamadores.
Paso 6: Diseñar telemetría de auditoría y exposición
El plano de control registra quién publicó, aprobó, ejecutó canaries o hizo rollback, y en qué momento. El plano de datos registra la clave de la flag, versión, resultado, rama de regla, versión del SDK y un hash anónimo del sujeto, nunca correos electrónicos en bruto, IP o el contexto completo. Aísla el muestreo, la retención y el acceso por inquilino, y vincula los resultados a métricas para detectar el impacto del despliegue canary.
Paso 7: Verificar rollbacks y migraciones
Reproduce contextos fijos contra cada versión de reglas y compara los resultados entre SDKs de distintos lenguajes. Pon a prueba escenarios de notificaciones perdidas, cachés corruptas, caídas del plano de control, desfase de reloj, rollbacks parciales y actualizaciones de proveedores. Un rollback crea una nueva versión en lugar de reescribir el historial; compara la distribución de versiones de instancias y las métricas de negocio tras completarlo.
Ejemplo de respuesta de alta calidad
El plano de control gestiona comprobaciones de tipos, compilación, aprobaciones, versiones y despliegues canary; los SDKs evalúan instantáneas locales con suma de verificación para ofrecer baja latencia y operación sin conexión. El contexto fusiona los ámbitos global, de transacción y de invocación con un orden de sobrescritura fijo y una lista de permitidos para campos sensibles. Las instancias utilizan notificaciones combinadas con sondeo, con un límite máximo de obsolescencia y una regla de versión monótona. Los errores devuelven valores predeterminados tipados o los últimos válidos conocidos, con opciones de fallo cerrado para flags críticas. Las auditorías preservan la cadena de publicaciones y rollbacks, los registros de exposición solo contienen versiones, resultados y claves anónimas, y el rollback es una nueva versión verificada mediante repeticiones en SDKs y simulacros de fallos.
Errores comunes
- Llamar al plano de control sincrónicamente para cada evaluación, acoplando la disponibilidad del negocio a este.
- Almacenar valores en caché sin versión, impidiendo explicar rollbacks y datos desactualizados.
- Dejar el orden de fusión del contexto al comportamiento del SDK de cada lenguaje, generando resultados discrepantes entre servicios.
- Registrar atributos completos de usuario o correos electrónicos.
- Sobrescribir configuraciones antiguas durante un rollback, perdiendo el historial de auditoría y reproducción.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Puede continuar la evaluación si el servicio de configuración está caído?
Usa la última instantánea confiable y expón su versión, antigüedad y origen. Más allá del umbral máximo de obsolescencia, elige un valor predeterminado basado en riesgo, bloquea la operación o requiere intervención humana en lugar de operar silenciosamente de forma indefinida.
Pregunta de seguimiento 2: ¿Cómo mantienes la consistencia entre SDKs de diferentes lenguajes?
Especifica la normalización, tipos, fusión de contexto y motivos de error, y proporciona vectores versionados de entrada/salida entre lenguajes. Un proveedor puede ejecutar reglas complejas centralmente mientras los SDKs comparten el mismo protocolo y ciclo de vida.
Pregunta de seguimiento 3: ¿Cómo mantienes estable el porcentaje de un canary?
Asigna a cubos (buckets) una clave de sujeto anónima y estable mediante un algoritmo de hash explícito. Una versión de regla fija asigna al mismo sujeto la misma variante en cada instancia. Modificar el algoritmo o la sal (salt) crea una nueva versión con un impacto de migración documentado.
Pregunta de seguimiento 4: ¿Por qué utilizar hooks?
Los hooks pueden añadir contexto antes de la evaluación, validar un valor después de ella o emitir telemetría, pero requieren un orden explícito, tiempos de espera y gestión de errores. No deben modificar silenciosamente los tipos de flag ni omitir la auditoría.
Pregunta de seguimiento 5: ¿Cómo se elimina una flag de forma segura?
Identifica referencias en el código, tráfico de evaluación y ramas predeterminadas, publica una versión con valor fijo, obsérvala y luego elimina las reglas y los metadatos del SDK. Conserva las versiones históricas y los registros de migración para que las instancias antiguas no reciban un tipo desconocido.