O fan-out de webhook que você não precisou construir

# Sender side — your Stripe webhook handler.
# Pipe holds the body until 12 readers are attached.
curl -X POST "https://api.hoody.com/api/v1/pipe/billing?n=12" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary "@stripe-event.json"

# Receiver side — one of twelve subscriber containers.
# Same path, same n. Streams the event body when fan-out is ready.
curl -N "https://api.hoody.com/api/v1/pipe/billing?n=12" \
  -H "Authorization: Bearer $HOODY_TOKEN" | ./billing-handler.sh

# n must match on both ends — mismatch returns 400.
# Default n=1 is point-to-point. n=12 is fan-out for twelve.

Mesma URL, mesma query string, nas duas pontas. A conexão do sender é o broker; as conexões dos leitores são o consumer group. O backpressure é por socket, não por tópico, porque não existe tópico — existe um corpo em trânsito e doze sockets puxando.

• Sem fila para provisionar

  Sem SQS, sem cluster Kafka, sem exchange RabbitMQ. O pipe é a fila, e ele vive por uma mensagem de cada vez.

• Sem contabilidade de consumer-group

  Sem offsets, sem commits, sem rebalances. O pipe segura o corpo até n sockets se conectarem — esse é o modelo de coordenação inteiro.

• Sem DLQ para drenar

  Se o sender desconecta sem n leitores prontos, o pipe expira (TTL de 5 min) e o Stripe tenta de novo. Sem balde de mensagens venenosas para vigiar.

• Sem SDK por linguagem

  Os assinantes são loops curl. Os senders são curl. O protocolo é HTTP. Qualquer coisa que consegue acertar uma URL pode entrar no cluster.

• Backpressure por socket

  Um leitor lento limita a própria conexão. Os outros onze seguem fluindo à velocidade total. Não existe head-of-line blocking pela frota.

• Esquecível por padrão

  O corpo some no momento em que o último leitor desconecta. Sem política de retenção para configurar, sem log-compaction para agendar, sem job de delete-on-request por GDPR para escrever.