10. IX. Desechabilidad

Maximiza la robustez con arranque rápido y apagado elegante.

Procesos como “desechables”

Los procesos de una aplicación twelve-factor deben poder iniciarse y finalizarse en cualquier momento sin drama. Esta propiedad es lo que habilita escalado elástico (Factor VIII), despliegues rápidos y recuperación automática ante fallos.

Arranque rápido

Un proceso debe minimizar su tiempo de arranque — idealmente, estar listo para recibir tráfico en segundos. Esto tiene beneficios concretos:

• El gestor de procesos puede mover procesos entre máquinas físicas con fricción mínima.
• El escalado hacia arriba responde rápido a picos de demanda.
• Un despliegue nuevo (Factor V) reemplaza procesos viejos por nuevos sin ventanas largas de indisponibilidad.

Apagado elegante (graceful shutdown)

Los procesos deben terminar de forma segura al recibir una señal SIGTERM desde el gestor de procesos:

Para un proceso web: deja de escuchar en su puerto (rechaza conexiones nuevas), mientras deja que las solicitudes ya en curso terminen. Las peticiones HTTP deben ser cortas por diseño; si se usa long-polling, el cliente debe reconectar automáticamente ante el cierre.

Para un proceso worker: devuelve a la cola cualquier trabajo que tenía tomado y no terminó — por ejemplo, con un NACK en RabbitMQ, o dejando que Beanstalkd lo reencole automáticamente por timeout.

sequenceDiagram
    participant GP as Gestor de procesos
    participant P as Proceso worker
    participant Q as Cola

    GP->>P: SIGTERM
    P->>Q: NACK del trabajo en curso
    P->>GP: proceso termina limpiamente

Esto exige que los trabajos sean reentrantes e idempotentes: reintentarlos desde cero no debe producir efectos duplicados o inconsistentes.

Robustez ante fallos repentinos

SIGTERM es el caso feliz. También hay que estar preparado para finalizaciones abruptas (caída de hardware, kill -9). La estrategia aquí no es evitarlas —son inevitables— sino diseñar para que no dañen datos: colas robustas (como Beanstalkd) que recuperan automáticamente trabajos de procesos caídos son un ejemplo.

El enfoque crash-only software lleva esta idea al extremo: diseñar el sistema asumiendo que la única forma de “apagarlo” es matarlo, de modo que arrancar desde cero después de un crash sea siempre seguro y predecible.

Checklist del factor IX

• El tiempo de arranque de un proceso se mide en segundos, no en minutos.
• Los procesos web manejan SIGTERM dejando de aceptar conexiones nuevas y cerrando las existentes con gracia.
• Los procesos worker devuelven a la cola cualquier trabajo incompleto al recibir SIGTERM.
• Los trabajos de cola son reentrantes e idempotentes: reintentarlos no causa efectos duplicados.
• El sistema tolera una finalización abrupta (crash) sin pérdida de datos críticos.

Con procesos rápidos de crear y destruir, el siguiente factor exige que dev y producción se parezcan lo más posible: la paridad dev/prod.