Prompt y escenario
Un SaaS B2B utiliza feature flags para controlar las funciones de los planes. A medida que crecen las actualizaciones, bajas, periodos de prueba y experimentos graduales, las reglas se superponen y el equipo de soporte no puede explicar por qué un cliente tiene acceso a una función. Ingeniería propone un modelo independiente de derechos de suscripción (entitlements). Explica cómo estructurarías el problema, evaluarías las opciones, priorizarías el alcance y demostrarías que la migración vale la pena.
Qué está evaluando el entrevistador
- Si distingues entre autorización comercial, asignación de experimentos, configuración operativa y switch de apagado de emergencia (kill switch).
- Si tomas decisiones de balance (trade-offs) de producto que consideren la experiencia del cliente, el riesgo de ingresos, el costo de ingeniería y la velocidad de entrega.
- Si puedes diseñar una migración gradual, auditabilidad y planes de reversión (rollback) en lugar de limitarte a proponer una reescritura de permisos.
- Si demuestras que el modelo mejora los resultados en lugar de limitarse a agregar abstracción.
Preguntas aclaratorias para hacer primero
- ¿Los conflictos provienen de actualizaciones, bajas, pruebas, límites regionales o experimentos internos, y cuántos clientes o ingresos en dólares se ven afectados?
- ¿Los derechos se otorgan por producto, plan, complemento (add-on), usuario (seat) o uso? ¿Cuándo entran en vigor los cambios y existen compromisos contractuales?
- ¿Los feature flags también gestionan despliegues (rollouts), pruebas A/B, deshabilitaciones de emergencia y pruebas internas? ¿Se pueden separar estas reglas?
- ¿Qué tickets de soporte, correcciones manuales, requisitos de auditoría y dependencias downstream existen en la actualidad?
Una respuesta de 30 segundos
Dividiría el problema en "¿tiene el cliente derecho a usar esto?" y "¿debería esta solicitud formar parte de un experimento?". Los derechos (entitlements) deben derivarse de los planes, complementos y el estado de la suscripción, y explicar las actualizaciones, bajas y revocaciones. Los feature flags deben encargarse del despliegue, los experimentos y la deshabilitación de emergencia. Si mezclarlos provoca fugas de ingresos, costos de soporte o riesgo de auditoría, comenzaría con una API autoritativa de lectura de derechos, mantendría un flag como filtro adicional y migraría las rutas de alto valor por etapas. Mediría las concesiones incorrectas, el tiempo de entrada en vigor de las actualizaciones, los tickets de soporte, la velocidad de experimentación y el costo de mantenimiento en lugar de las líneas de código.
Análisis a fondo
1. Mapear las decisiones y los límites de propiedad
Clasifica cada regla como un derecho comercial, asignación de experimento, configuración operativa o switch de apagado de seguridad (kill switch). Un derecho comercial responde a qué compró el cliente; la asignación de experimento responde a qué grupo recibe una solicitud; una configuración operativa controla valores predeterminados; un kill switch deshabilita temporalmente un comportamiento. Cuando un solo flag expresa dos intenciones, la prioridad se vuelve difícil de explicar y auditar.
2. Definir las fuentes de derechos y el tiempo de entrada en vigor
El modelo debe especificar el mapeo de productos a funciones, el estado de la suscripción, los complementos, los límites de cantidad y el momento en que entra en vigor. Una actualización puede otorgar acceso de inmediato, mientras que una baja entra en vigor en el siguiente periodo de facturación; el fin de una prueba, reembolsos, morosidad y cancelaciones necesitan estados explícitos. Para cada cambio, documenta cuándo se otorga, revoca, anula y comunica el acceso para que el soporte no tenga que adivinar.
3. Decidir si se justifica un modelo independiente
Utiliza cuatro dimensiones: riesgo de ingresos o de cumplimiento por autorización incorrecta, cantidad de combinaciones de reglas, frecuencia de cambios e implementación duplicada entre servicios. Un producto único y estable sin exigencias de auditoría puede requerir solo una configuración simple. A medida que crecen los planes y experimentos, un modelo de derechos separa los compromisos comerciales de la mecánica de lanzamiento, pero agrega costos de migración, consistencia de caché y aprendizaje operativo.
4. Diseñar el alcance mínimo viable
Comienza con un producto de alto valor y unos pocos derechos estables, como la lectura de reportes y la exportación de datos. Proporciona una consulta de derechos de solo lectura que devuelva la fuente, la versión, el tiempo de entrada en vigor y el motivo de denegación. Un feature flag puede mantenerse como una condición adicional, pero no puede otorgar una capacidad que el cliente no compró. Coloca las excepciones históricas no explicadas en una lista de migración en lugar de intentar resolver todo a la vez.
5. Planificar lecturas en sombra (shadow reads), migración y reversión (rollback)
Comienza con un cálculo en sombra: evalúa el resultado del flag heredado y el resultado del nuevo modelo de derechos de forma simultánea, registra las diferencias y no alteres ningún acceso. Cuando las diferencias sean estables, habilita la nueva ruta para usuarios internos y clientes de bajo riesgo, y luego expándela. Conserva el resultado anterior, los registros de auditoría y un mecanismo de fallback a nivel de cliente; si las tasas de concesiones o denegaciones incorrectas superan un umbral, restaura la ruta anterior y congela los cambios de derechos.
6. Validar con resultados y retroalimentación de clientes
Monitorea la tasa de concesiones incorrectas, la tasa de denegaciones incorrectas, el tiempo de entrada en vigor de actualizaciones o bajas, los tickets de soporte, las correcciones manuales, el tiempo de lanzamiento de experimentos y la latencia de decisión de derechos. Segmenta el riesgo de ingresos y cumplimiento según el valor del cliente. Entrevista a soporte, ventas y clientes sobre si pueden explicar por qué un acceso existe o se deniega; si solo los ingenieros pueden inspeccionar los registros, el modelo aún no está productizado.
Una respuesta completa y sólida
Separaría la autorización comercial, la asignación de experimentos, las configuraciones operativas y los switches de apagado de emergencia; luego cuantificaría el riesgo de ingresos, soporte y auditoría que conlleva mezclarlos. El modelo de derechos responde a qué compró el cliente y cuándo inicia o termina; los feature flags gestionan los despliegues y experimentos y no pueden otorgar una capacidad fuera del plan. Comenzaría con una API de solo lectura para un producto de alto valor, compararía los resultados heredados y los nuevos en modo sombra, y luego aumentaría gradualmente con fallback a nivel de cliente y registros de auditoría. Establecería controles según concesiones incorrectas, denegaciones incorrectas, tiempos de actualización, tickets, velocidad de experimentos y costo de mantenimiento. Solo cuando la complejidad de las reglas y el riesgo superen de forma consistente el costo de una configuración simple, expandiría el modelo independiente.
Modos de falla comunes
- Llamar "permisos" tanto a los feature flags como a los derechos de suscripción sin separar los compromisos comerciales de los experimentos.
- Hablar de una reescritura de ingeniería sin cuantificar la fuga de ingresos, el costo de soporte o el riesgo de cumplimiento.
- Migrar a todos los clientes a la vez sin lecturas en sombra, monitoreo de diferencias o switches de reversión.
- Ignorar los tiempos de entrada en vigor para actualizaciones, bajas, reembolsos, morosidad y vencimiento de pruebas.
- Fijarse únicamente en la latencia del sistema sin comprobar si ventas, soporte y los clientes pueden explicar el acceso.
Preguntas de seguimiento y extensiones
Pregunta de seguimiento 1: ¿Se pueden eliminar los feature flags con el tiempo?
No de manera categórica. Los despliegues, experimentos y switches de apagado de emergencia aún necesitan flags; lo que se debe eliminar son las rutas que codifican autorización comercial en flags. Retira los flags de autorización heredados en función del uso, la cobertura de auditoría y la finalización de la migración.
Pregunta de seguimiento 2: ¿Deben almacenarse en caché los resultados de los derechos?
Se pueden almacenar en caché con invalidación explícita para cambios de suscripción, reembolsos, morosidad y revocación de emergencia. La revocación de alto riesgo debe priorizar la entrada en vigor oportuna; la tasa de aciertos de caché (hit rate) no puede ocultar errores de autorización.
Pregunta de seguimiento 3: ¿Cómo se maneja una función compartida entre varios productos?
Define la función como una capacidad reutilizable, asígnala a productos y complementos por separado, y devuelve la fuente de concesión en el resultado. De este modo, soporte puede explicar qué relación de compra proporciona el acceso en lugar de depender de una regla implícita basada en el nombre del producto.
Pregunta de seguimiento 4: ¿Cuándo no vale la pena un modelo de derechos independiente?
Mantén una configuración simple cuando haya pocos productos, reglas estables, sin autorización entre servicios ni presión de auditoría, y cuando el mantenimiento manual cueste menos que el riesgo de migración. Reevalúa en función de la cantidad de reglas, los tickets por acceso incorrecto y el riesgo de ingresos.