
Sesenta contenedores en un servidor
Un servidor bare-metal ejecuta decenas a cientos de contenedores Hoody. KSM y dedup BTRFS hacen que el costo marginal sea casi cero.
Estás corriendo una migración de ocho horas. Cinco personas quieren ver el estado sin consumir un slot de receptor ni interrumpir el stream. Añade ?progress a la URL del pipe. Cualquiera que la abra obtiene un dashboard HTML en vivo — bytes transferidos, velocidad actual, ETA, transiciones de estado. La migración corre a velocidad máxima sin importar cuántos ojos estén mirando.
?progress es una lectura de canal lateral. Nunca reclama un slot de receptor, nunca crea backpressure, nunca toca los bytes. La migración corre a ancho de banda completo sin importar cuántos estén mirando.
Ella pega la URL del pipe con ?progress en su navegador del móvil. El dashboard HTML aparece al instante — estado: esperando, 0% — sin instalar, sin login, sin slot de receptor consumido.
SSE impulsa un evento state: streaming. La barra de progreso salta al 22%, los bytes suben, MB/s se estabiliza en 118. El dashboard se actualiza cada 250 ms sin un solo recargo de página.
Ella cierra la pestaña. Su conexión de espectador cae. La migración no se entera — nunca estuvo en el camino de los datos. El emisor y su único receptor real siguen adelante.
Ella reabre la URL al amanecer. El dashboard muestra un evento done: 7.6 GB transferidos, 8h 2m, sin errores. El estado del lado del servidor sobrevive al refresh — los rezagados siempre ven la línea final.
Ella reenvía la URL al Slack del equipo. Tres ingenieros la abren y ven el mismo estado done. Sin hilo de status que cerrar, sin panel de Grafana que desmarcar. Una URL, cinco testigos, cero interrupciones.
# 1. Sender — eight-hour migration. Same as always.
tar czf - /var/lib/postgres | curl -T - "$PIPE/api/v1/pipe/migration"
# 2. Receiver — the only client that matters for backpressure.
curl "$PIPE/api/v1/pipe/migration" | tar xzf - -C /restore
# 3. Boss opens the URL on her phone. HTML dashboard. No setup.
# => https://pipe.hoody.com/api/v1/pipe/migration?progress
# 4. You want SSE for a Slack bot? Same URL, different Accept.
curl -N -H "Accept: text/event-stream" \
"$PIPE/api/v1/pipe/migration?progress" \
| grep -E '^event: (progress|state|done)'
# event: state \n data: '{'"state":"streaming","receivers":1'}'
# event: progress \n data: '{'"bytes":5046464512,"mbps":118,"etaSec":840'}'
# event: done \n data: '{'"bytes":8160000000,"durationSec":28800'}'Tres tipos de evento SSE. state para transiciones (idle → waiting → streaming → complete), progress cada 250 ms mientras fluyen los bytes (bytesTransferred, velocidad, ETA), done una vez al final con stats finales. Hasta cincuenta espectadores por ruta, cada uno con una ventana de conexión de cinco minutos.
?progress es un canal lateral. Jefe, compañero, cliente externo, on-call — todos abren la misma URL. Ninguno afecta la transferencia. Todos ven el mismo estado en vivo.
Marca la URL en su móvil. La consulta dos veces al día.
Dashboard HTML, sin loginCurl SSE en un webhook de Slack. Bot de status de una línea.
text/event-stream, misma URLIncrustado en una página de status pública. Consulta cada 30 s.
0 slots de receptor, estado en vivo completoCableado a PagerDuty vía el evento done. Aviso cuando termina.
event: done, activador de una sola vezMirar la migración tiene su propia URL. La migración no se entera.
Cada equipo tiene una forma de responder '¿cuánto falta?'. La mayoría de esas formas cuestan un servicio que correr, un dashboard que conectar o un canal de chat que cuidar. Un parámetro de query sobre la URL del pipe no cuesta nada de eso.
Envía la URL. Deja de enviar actualizaciones.