Desarrollador Full-stack: pregunta de entrevista
¿Cómo publicas una funcionalidad full-stack de forma segura?
Publica un cambio full-stack con API y base de datos compatibles, controles automáticos, flags o rollout progresivo, monitorización técnica y de negocio y un rollback probado que no dependa de revertir datos irreversibles.
Respuesta directa
Qué debe cubrir una buena respuesta
Cómo funciona
Una release segura separa el despliegue de la exposición. El cambio de base de datos sale primero en forma compatible, el backend sale soportando clientes viejos y nuevos, y el frontend sale detrás de un feature flag para activar el nuevo comportamiento a un porcentaje de usuarios y apagarlo en segundos sin desplegar. Las comprobaciones automáticas custodian cada paso, se vigilan métricas de salud y de negocio durante el despliegue, y el plan de rollback está ensayado: el código vuelve atrás con el artefacto anterior, mientras los cambios de datos se diseñan para no necesitar nunca marcha atrás.
Ejemplo
Un flujo de checkout nuevo salió así: migración con columnas nullable, despliegue de API que lee ambas formas, despliegue del frontend con el flujo tras un flag al 0 por ciento, y luego 5, 25 y 100 por ciento en dos días vigilando conversión y tasa de errores por cohorte. Cuando la etapa del 25 por ciento mostró una caída de conversión en Safari, el flag volvió al 5 por ciento en un minuto y el arreglo salió al día siguiente.
Errores frecuentes
- Acoplar una migración destructiva al despliegue, de modo que el rollback es imposible.
- Publicar al 100 por ciento de golpe y descubrir el problema por tickets de soporte.
- Dejar feature flags obsoletos en el código durante años.
Una estructura útil para responder
Responde desde tu propia experiencia.
No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.
Abre el espacio de trabajo de escritorio y ensaya una respuesta clara con tus propias palabras.