Sessenta contêineres em um servidor
Um servidor bare-metal roda dezenas a centenas de contêineres Hoody. KSM e dedup do BTRFS deixam o custo marginal perto de zero.
Você está rodando uma migração de oito horas. Cinco pessoas querem ver o status sem consumir um slot de receiver nem interromper o stream. Anexe ?progress à URL do pipe. Quem abrir recebe um dashboard HTML ao vivo — bytes transferidos, velocidade atual, ETA, transições de estado. A migração roda à velocidade total, independente de quantos olhos estiverem assistindo.
?progress é uma leitura separada no caminho do pipe que escuta o estado da transferência sem reivindicar um slot de receiver. A migração não percebe. O navegador vê um dashboard HTML; o curl vê um feed SSE limpo.
Ela cola a URL do pipe com ?progress no navegador do celular. O dashboard HTML aparece na hora — state: waiting, 0% — sem instalação, sem login, sem consumir um slot de receiver.
O SSE envia um evento state: streaming. A barra de progresso salta para 22%, os bytes sobem, o MB/s estabiliza em 118. O dashboard se atualiza sozinho a cada 250 ms sem um único reload da página.
Ela fecha a aba. A conexão de espectador dela cai. A migração nem percebe — ela nunca esteve no caminho dos dados. O sender e seu único receiver de verdade seguem em frente.
Ela reabre a URL ao amanhecer. O dashboard mostra um evento done: 7,6 GB transferidos, 8h 2m, sem erros. O estado no servidor sobrevive ao refresh — quem chega atrasado sempre vê a linha final.
Ela encaminha a URL para o Slack do time. Três engenheiros abrem e veem o mesmo estado done. Sem thread de status para fechar, sem painel do Grafana para desfavoritar. Uma URL, cinco testemunhas, zero interrupções.
# 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]Três tipos de evento SSE. state para transições (idle → waiting → streaming → complete), progress a cada 250ms enquanto bytes fluem (bytesTransferred, velocidade, ETA), done uma vez no final com estatísticas finais. Até cinquenta espectadores por caminho, TTL de conexão de trinta minutos, linger de trinta segundos pós-transferência para que retardatários vejam a linha de sucesso.
O mesmo endpoint ?progress serve uma aba de navegador, um pipeline curl e uma página de status que faz polling em segundo plano. Nenhum deles desacelera a transferência.
Salva a URL no celular. Confere duas vezes por dia.
Dashboard HTML, sem loginFaz curl do SSE para um webhook do Slack. Bot de status em uma linha.
text/event-stream, same URLEmbutido em uma página de status pública. Consulta a cada 30 s.
0 slots de receiver, estado ao vivo completoConectado ao PagerDuty pelo evento done. Avisa quando termina.
event: done, gatilho únicoAssistir à migração tem URL própria. A migração não percebe.
Todo time tem um jeito de responder 'a quantas anda?'. A maioria desses jeitos custa um serviço para rodar, um dashboard para ligar ou um canal de chat para vigiar. Um query parameter na URL do pipe não custa nada disso.
Mande a URL. Pare de mandar updates.