Planteamiento y contexto adecuado
Esta es una pregunta de diseño de sistemas. El punto central no es elegir el versionado por URL o por encabezados; es diseñar un plano de control del ciclo de vida de la API. Un cambio de contrato debe traducirse en un análisis de impacto, descubrimiento de consumidores reales, verificaciones del comportamiento antiguo/nuevo, migración escalonada y un apagado basado en evidencias. Microsoft recomienda preservar la compatibilidad hacia atrás cuando sea posible, y de manera similar, Google Cloud aconseja intentar primero la evolución compatible. La entrevista te pide convertir esos principios en un sistema que funcione entre distintos equipos.
Qué evalúa el entrevistador
- Si distingues entre la compatibilidad de formato, los cambios semánticos de entidades y los cambios genuinamente disruptivos.
- Si conectas los contratos de API, un inventario de consumidores, el tráfico en tiempo de ejecución y el trabajo de migración.
- Si diseñas pruebas de compatibilidad, despliegues graduales, alertas, notificaciones y reversión en lugar de limitarte únicamente a las etiquetas de versión.
- Si puedes explicar el costo operativo de mantener múltiples versiones, el riesgo de conversión de datos y los límites organizacionales.
Aclaraciones que se deben hacer primero
Confirma si la API es interna, para socios o pública; si los consumidores pueden identificarse por completo; y los objetivos de tráfico, latencia y disponibilidad. Aclara si el campo es opcional, si cambia su significado y si involucra lecturas, escrituras o datos persistidos. Pregunta sobre la existencia de una fuente de contrato como OpenAPI u otra, SDK para clientes, canales de notificación, ventanas de soporte, requisitos de cumplimiento y duración de la reversión. Si la escala no está especificada, expón tus suposiciones.
Estructura de respuesta en 30 segundos
Diseñaría cinco etapas: registro de contratos, descubrimiento de impacto, validación de compatibilidad, coordinación de la migración y evidencia para el apagado. Cada contrato de API entra en un registro; un motor de reglas clasifica los cambios y luego combina dependencias estáticas y llamadas en tiempo de ejecución para identificar a los consumidores. Las versiones antigua y nueva se ejecutan en paralelo mientras los consumidores reciben avisos con una fecha límite y una guía de migración. Durante el despliegue gradual, se registran el éxito, los errores y el tráfico residual por versión. Se apaga solo después de que los consumidores críticos hayan migrado, la evidencia de migración esté completa, la reversión haya sido ensayada y un responsable apruebe el cambio.
Respuesta profunda paso a paso
1. Construir un registro de contratos y reglas de cambio
El registro almacena cada API, versión, responsable, semántica de campos, alcance de autenticación, estado de soporte, fecha de desaprobación y documentación de migración. Una solicitud de cambio incluye un diff del contrato, y el motor de reglas señala campos eliminados, enums reducidos, cambios en la obligatoriedad, semántica de errores alterada y cambios en las relaciones de entidades. Agregar un campo ignorable a menudo es compatible, pero no se puede asumir que los clientes ignoren correctamente los campos desconocidos; los equipos necesitan una vía de excepción respaldada por evidencias.
2. Descubrir consumidores y construir un grafo de impacto
Combina dependencias de repositorios, registros de gateway, telemetría de service mesh, registros de SDK y declaraciones en un grafo de API-versión-consumidor. El descubrimiento estático puede pasar por alto solicitudes construidas dinámicamente, mientras que el descubrimiento en tiempo de ejecución puede omitir tareas poco frecuentes, por lo que debes marcar la fuente de evidencia, la hora de última detección y la confianza. Para los clientes externos, conserva solo los identificadores necesarios de inquilinos y aplicaciones en lugar de tratar los registros como datos personales indefinidos.
3. Validar la compatibilidad con compuertas de seguridad
Para cada cambio, ejecuta pruebas de contrato, repeticiones de tráfico de consumidores y comparaciones de tráfico muestreado. Verifica la semántica de respuesta en las lecturas y comprueba que las escrituras de clientes antiguos no pierdan datos ni creen efectos secundarios no deseados. Inicia los cambios disruptivos en tráfico sombra o en una cohorte pequeña de inquilinos; el enrutamiento de versiones y las feature flags deben ser reversibles. Preserva la versión antigua ante fallas en lugar de asumir que un conjunto de pruebas superado sea una prueba respecto a los consumidores no evaluados.
4. Coordinar avisos, migración y operación multiversión
Un servicio de avisos envía guías de migración, plazos, solicitudes de ejemplo y contactos según el consumidor, la gravedad y el contrato de soporte; los clientes externos necesitan una página de estado consultable o una consola. El trabajo de migración registra un responsable, bloqueadores, evidencia de validación y la última llamada exitosa. Múltiples versiones aumentan el costo de pruebas, despliegue y monitoreo, por lo que se debe fijar un límite de versiones, etapas de desaprobación y una ruta de migración en lugar de soportar cada versión indefinidamente.
5. Decidir el apagado, observar y recuperar
Antes del apagado, verifica que los consumidores críticos se hayan actualizado, que las llamadas residuales estén por debajo del umbral, que no haya regresión de errores, que la conversión de datos sea reversible y que el soporte esté preparado. Utiliza cohortes y ventanas de tiempo: detén nuevas incorporaciones, devuelve un error claro de desaprobación junto con un enlace de migración a las llamadas antiguas y luego deshabilita el enrutamiento. Monitorea fallas de compatibilidad, tráfico de la versión antigua, avance de la migración, entrega de avisos, recuento de reversiones y errores segmentados por consumidor. Kubernetes muestra cómo los niveles de estabilidad, los períodos mínimos de soporte, la conversión y las restricciones de reversión pueden ser políticas explícitas; configura tales restricciones para la organización en lugar de copiar sus fechas universalmente.
Ejemplo de respuesta de alta calidad
Aclararía los tipos de consumidores, la fuente del contrato, la semántica de lectura/escritura del campo que se elimina, las obligaciones de notificación externa y la duración de la reversión. Un registro de contratos alimenta un motor de reglas de cambio que identifica diferencias disruptivas y las vincula a un grafo de impacto construido a partir de dependencias de código, registros de gateway y telemetría de service mesh, con frescura de evidencia. Las pruebas de compatibilidad, las repeticiones de tráfico de consumidores y el tráfico gradual validan el comportamiento antiguo y el nuevo; un servicio de avisos envía a cada consumidor una guía de migración y una fecha límite. Las versiones se ejecutan en paralelo y el trabajo de migración almacena la evidencia de validación. Solo después de que los consumidores críticos migren, el tráfico residual y los errores cumplan los umbrales, se ensaye la reversión y un responsable lo apruebe, retiramos la ruta antigua. Los registros de auditoría cubren cambios, avisos, observaciones y reversiones para que los clientes desconocidos no queden desconectados de golpe.
Errores comunes
- Debatir sobre etiquetas de URL, encabezados o versiones semánticas sin un descubrimiento de consumidores y evidencia de apagado.
- Depender únicamente de la búsqueda de código estático o de un solo registro de acceso, pasando por alto llamadas dinámicas y poco frecuentes.
- Asumir que eliminar un campo opcional es automáticamente seguro sin probar el procesamiento real de los clientes.
- Lanzar la nueva versión y cerrar de inmediato la antigua sin un despliegue gradual ni capacidad de reversión.
- Soportar todas las versiones para siempre sin calcular los costos de prueba, monitoreo y conversión.
- Enviar un único correo electrónico sin fecha límite, responsable, ruta de escalamiento o métricas segmentadas.
Preguntas de seguimiento y respuestas
¿Cómo decides apagar cuando no se puede encontrar a un cliente externo?
Trata el uso desconocido como un estado de riesgo, amplía la ventana de observación, incrementa la telemetría y contacta al titular del contrato u ofrece un diagnóstico de migración. Tener cero registros no prueba que no haya uso; utiliza una política de rechazo recuperable y un mecanismo de emergencia antes del apagado.
¿Agregar un campo de respuesta siempre es compatible?
No. Las reglas pueden clasificarlo como habitualmente compatible, pero las repeticiones de tráfico reales de consumidores, las matrices de SDK y las muestras de errores aún necesitan validarlo. Los validadores de esquema estrictos pueden requerir una migración o un límite de versión independiente.
¿Cómo se migran de forma segura los datos escritos por clientes antiguos?
Define primero los mapeos semánticos y las condiciones de no pérdida de datos, luego utiliza lecturas duales, escrituras duales o conversión fuera de línea con registros de versión. La conversión debe ser verificable y reversible; no cambies de forma silenciosa el significado del negocio en tiempo de lectura.
¿Qué pasa si un cliente no puede actualizarse antes de la fecha límite?
Ofrece una ventana de compatibilidad limitada, un adaptador o una migración asistida según el contrato y el riesgo, registrando el costo, el responsable y una nueva fecha de salida. Las excepciones deben reducir el tráfico desconocido en lugar de hacer que la versión antigua sea permanente.
¿Cómo evitas que el plano de control sea un punto único de falla?
El enrutamiento del plano de datos no debe depender de una escritura en tiempo real en el plano de control. Almacena en caché la política de versiones aprobada y mantén la última configuración segura durante una falla del plano de control. Los servicios de registro, notificaciones y métricas pueden recuperarse de forma asíncrona, mientras que el apagado requiere doble aprobación y reversión explícita.