🧪 Problem-Driven Systems Lab
❄️ Caso 18 · Resiliencia

Arranque en frio y retraso del autoescalado

El autoescalador suma instancias y la tasa de error sube con cada una: el proceso esta vivo y el healthcheck en verde mucho antes de que la instancia pueda servir.

OPERATIVO 🐘 PHP🐍 Python🟢 Node.js☕ Java🔵 .NET🐹 Go🦀 Rust
Leer el caso completo Codigo del caso ↗

📈 Que cambia para el negocio

Elimina los 503 durante los escalados y habilita autoescalado agresivo con confianza, que es la forma de que el autoescalado ahorre dinero en vez de mover el problema.

💼 Que demuestra tecnicamente

Es el unico caso que mide una propiedad del runtime en vez de simularla — la curva de calentamiento de cada uno, con el mismo codigo — y muestra que el indicador honesto no es cuanto tarda un servicio en arrancar sino cuanto tiempo afirma estar disponible sin estarlo.

✅ Evidencia que deja

  • Contrasta /boot-cold y /boot-warmed con availability_pct medida DURANTE el escalado.
  • Mide warmup_speedup_x con el mismo lazo entero en los 7 runtimes: Java 51,9x contra Rust 1,00x.
  • Separa /health de /ready y expone health_vs_ready_gap_ms, la ventana exacta de la mentira.

👀 Que mirar al ejecutarlo

  • Si rejected_cold_start es mayor que cero en la variante fria y exactamente cero en la corregida.
  • Si health_vs_ready_gap_ms coincide con la ventana en que el proceso decia estar vivo sin poder servir.
  • Si warmup_speedup_x separa a los runtimes con JIT de los compilados AOT con el mismo codigo.
Honestidad: La curva de calentamiento se mide de verdad: el trabajo por peticion es un lazo entero puro sin sleep, identico en los 7. Lo modelado es la parte de I/O de la inicializacion (abrir pool, DNS, TLS), que va como sleep de io_ms porque esperar a la red no quema CPU y fijarla es lo que hace comparables a los 7. En la variante fria, p99_first_100_ms mezcla el calentamiento del runtime con la contencion de las instancias que estan inicializando — los dos efectos ocurren de verdad en produccion, pero es una mezcla. En PHP el solapamiento entre arranque y trafico tambien se modela, porque el servidor embebido es de un solo proceso.

Como esta resuelto en cada stack

Unico caso del lab que MIDE una propiedad del runtime en vez de simularla: el mismo lazo entero puro corre en los 7 stacks y warmup_speedup_x sale de comparar p99 de las primeras 100 peticiones contra p99 despues de 1000. Java 51,9x por compilacion en capas interp/C1/C2, .NET 2,3x por Tier 0/Tier 1 con OSR, Node 1,1x porque V8 llega a TurboFan enseguida, Python 1,8x que es contencion y no JIT, PHP 1,1x con el JIT apagado de fabrica, Go 1,0x y Rust 1,00x por compilar AOT. Mas la separacion liveness/readiness y el pool tibio con sync.Once, Lazy<T> y OnceLock

StackHealth check localComposeDetalle
🐘 PHP 8.3http://localhost:8100/18/healthcompose.root.ymlREADME del stack
🐍 Python 3.12http://localhost:8200/18/healthcompose.python.ymlREADME del stack
🟢 Node.js 22http://localhost:8300/18/healthcompose.nodejs.ymlREADME del stack
☕ Java 21http://localhost:8400/18/healthcompose.java.ymlREADME del stack
🔵 .NET 8http://localhost:8500/18/healthcompose.dotnet.ymlREADME del stack
🐹 Go 1.23http://localhost:8600/18/healthcompose.go.ymlREADME del stack
🦀 Rust 1.83http://localhost:8700/18/healthcompose.rust.ymlREADME del stack

El expediente completo

El caso no empieza en el codigo: empieza en el sintoma y termina en el postmortem.

ContextoEl sistema y su realidad operativa antes del problema.SintomasQue se observa desde fuera, con numeros.DiagnosticoComo se aisla la causa sin adivinar.Causas raizPor que ocurre, no solo donde duele.OpcionesLas alternativas reales y su coste.Trade-offsQue se gana y que se paga con la opcion elegida.Valor de negocioQue cambia para quien paga el sistema.PostmortemLa historia completa del incidente modelado.Comparativa entre stacksEl veredicto por runtime: que primitiva resuelve el caso y a que precio.
← Caso 17Caso 19 →