¿Cuáles son las técnicas reales para un despliegue sin tiempo de inactividad?
Los despliegues sin downtime descansan sobre una promesa mecánica precisa —ninguna petición perdida, ninguna conexión cortada— lograda mediante reemplazo rolling, chequeos de salud, drenado de conexiones y compatibilidad de esquema.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cuáles son las técnicas reales para un despliegue sin tiempo de inactividad?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#La promesa, dicha con precisión
"Despliegue sin downtime" no significa que nadie note que desplegaste: significa que ninguna petición se pierde, ninguna conexión se corta a la mitad, y ningún usuario ve un 5xx o una página en blanco porque la versión detrás del balanceador de carga cambió mientras la estaba usando. Es una afirmación más estrecha y más mecánica de lo que suena, y vale la pena ser precisos al respecto en una entrevista, porque las técnicas reales apuntan exactamente a esa afirmación, no a una noción más vaga de "despliegues suaves".
#Despliegue rolling: la forma por defecto
La técnica de trabajo es el despliegue rolling (por lotes): en lugar de detener todas las instancias y arrancar la versión nueva en todas partes a la vez, reemplazas instancias unas pocas a la vez mientras el balanceador de carga sigue enrutando tráfico a las instancias que en ese momento estén sanas. La mecánica que hace esto seguro, en orden:
- Sacar una instancia (o un lote pequeño) del pool activo del balanceador. Deja de recibir conexiones nuevas, pero las existentes no se matan.
- Drenar las conexiones en curso. La instancia termina las peticiones que ya había aceptado, hasta un período de gracia acotado, en lugar de ser matada a mitad de una petición.
- Detener el proceso viejo y arrancar la versión nueva.
- Ejecutar chequeos de disponibilidad (readiness) contra la versión nueva antes de que vuelva a unirse al pool — un readiness probe, distinto de un liveness probe, existe específicamente para responder "¿está esta instancia lista para recibir tráfico?", no solo "¿está vivo el proceso?".
- Volver a agregar la instancia al pool solo una vez que pasa el chequeo de disponibilidad, y repetir con el siguiente lote.
Los dos modos de falla que aparecen constantemente en incidentes reales vienen de saltarse un paso. Si te saltas el drenado, matas con SIGKILL a un proceso que todavía tiene conexiones abiertas, lo cual el cliente experimenta como una conexión reiniciada o una respuesta truncada: el deploy técnicamente tuvo éxito y aun así los usuarios vieron errores. Si te saltas la verificación de disponibilidad (o la confundes con un chequeo de vida), enrutas tráfico real hacia una instancia que todavía está calentando cachés o no terminó su secuencia de arranque, lo cual se manifiesta como un pico de errores que parece salir de la nada justo cuando empieza un deploy.
#Blue-green y canary no compiten con rolling — son compromisos de riesgo distintos
Un despliegue blue-green mantiene dos entornos completos e independientes y cambia el tráfico entre ellos de forma atómica, normalmente en el balanceador de carga o en la capa de DNS. Su ventaja sobre un despliegue rolling es la velocidad de rollback: si el entorno nuevo se comporta mal, devuelves el tráfico al viejo al instante, sin ninguna instancia quedando en un estado a medio migrar. Su costo es que pagas el doble de infraestructura durante el cambio, y cualquier base de datos que ambos entornos compartan igual tiene que tolerar que las dos versiones escriban en ella simultáneamente, al menos durante una ventana breve.
Un despliegue canary envía una porción pequeña y deliberadamente elegida de tráfico real (a menudo 1-5%) a la versión nueva, mientras el resto sigue golpeando la vieja, y solo aumenta gradualmente una vez que los dashboards confirman que la tasa de error y la latencia de la versión nueva coinciden con la línea base. Es el más lento de los tres en llegar al 100%, pero detecta problemas que solo se manifiestan bajo patrones reales de tráfico de producción, justo lo que un despliegue rolling —que llega a todos relativamente rápido— es malo detectando antes de que ya esté en toda la flota.
| Técnica | Velocidad de rollback | Costo de infra durante el deploy | Detecta bugs de patrón de tráfico temprano | Complejidad típica |
|---|---|---|---|---|
| Rolling | Moderada — revertir y volver a avanzar | Baja (una instancia extra a la vez) | Pobre — llega a todos rápido | Baja |
| Blue-green | Instantánea — revertir el tráfico | Alta (entorno duplicado completo) | Pobre — tráfico todo-o-nada | Moderada |
| Canary | Rápida — cortar el tráfico del canary a cero | Baja-moderada | Buena — primero una porción real pequeña | Alta (necesita comparar métricas) |
#El problema de compatibilidad que nadie menciona hasta que muerde
Las tres técnicas comparten un requisito fácil de pasar por alto porque vive en la base de datos, no en las herramientas de despliegue: mientras instancias viejas y nuevas corran una junto a la otra, ambas versiones de tu código tienen que funcionar correctamente contra el mismo esquema. Si tu código nuevo necesita una columna que todavía no existe, o tu código viejo se rompe en el momento en que desaparece una columna de la que depende, el "sin downtime" logrado en la capa de infraestructura se deshace por una ventana de cinco segundos de 500s en la capa de datos.
La respuesta estándar es el patrón expand-contract: agregar la columna nueva como nullable (o con un valor por defecto) y desplegar código que escriba tanto en la columna vieja como en la nueva —este es el paso de "expandir", y es seguro porque el código viejo, que no sabe que la columna nueva existe, sigue funcionando sin modificaciones. Una vez que todas las instancias corren código que escribe en ambas, se rellenan (backfill) las filas históricas. Una vez que el backfill termina y el monitoreo confirma que ya nadie lee la columna vieja, se despliega código que lee y escribe solo la columna nueva. Solo después de que ese deploy está completamente propagado se elimina la columna vieja: el paso de "contraer". Saltar directo de "agregar columna" a "eliminar columna vieja" en un solo deploy es exactamente lo que rompe los despliegues sin downtime en la práctica, porque durante la ventana del rollout algunas instancias todavía corren el código viejo que espera que la columna vieja exista.
🧠 Check your understanding
0/2 · 0/2 answered1. ¿Cuál es el propósito específico de un readiness probe, a diferencia de un liveness probe, durante un despliegue rolling?
2. En el patrón expand-contract para cambios de esquema, ¿por qué se conserva la columna vieja (sin eliminarla) inmediatamente después de agregar la nueva?