iwetan77/flume

Flume is a publish-subscribe message broker written in Go that uses QUIC, the network protocol underneath HTTP/3, as its transport. A broker is the middle process that lets one program send a message on a topic and any number of other programs subscribe to that topic and receive it. The novel thing about Flume is that every subscriber gets its own dedicated QUIC stream. The README spends most of its space explaining the why. Most brokers, including NATS and Redis pub/sub, run on TCP, where all data shares one ordered byte stream per connection. If one subscriber reads slowly, packets pile up and can delay other consumers, a problem called head-of-line blocking. Existing brokers work around it at the application layer by buffering, dropping messages, or disconnecting slow consumers. QUIC, by contrast, supports many independent streams on one connection, each with its own flow control. So in Flume a stalled subscriber only stalls its own stream, and the others keep moving. The flow is straightforward. A client opens a QUIC connection to the broker, opens a control stream, and sends a SUBSCRIBE frame. The broker then opens a new stream back to the client dedicated to that topic, and all messages for that topic travel on that stream only. If the subscriber falls behind, QUIC handles the backpressure on that stream in isolation. The wire format is binary with a fixed six-byte header: one byte for message type, one for topic-name length, four for payload length, then the topic and payload bytes. No JSON, no protobuf. The README includes a localhost benchmark under 10 percent simulated packet loss showing roughly 12 ms p99 latency versus 340 ms for NATS and 410 ms for Redis, attributed to QUIC's per-stream loss recovery. The project is MIT licensed.