Hanzo PubSub
The bus everything else rides
PubSub moves messages between services on port 4222. Publish to a subject and everyone listening on it — or on a pattern that matches it — has the message. Add a stream and those same messages are written down too, so a consumer that was offline can start from the beginning, from a sequence number, or from a timestamp. Streams, key-value buckets, an object store and request-reply are one server, not four.
More than pub/sub
Durable streams, key-value, an object store and request-reply — one server, one connection, one set of credentials.
Streams write it down
A stream captures the subjects you name and keeps them by age, by count or by bytes. A consumer starts at the beginning, at the newest message, at a sequence number or at a wall-clock time, and reads at the original pace or as fast as it can take them.
Acked, so nothing goes quiet
A message is redelivered until a consumer acknowledges it. Publishers that stamp a message id get duplicates collapsed inside a window — two minutes unless you say otherwise. Ack every message, ack a sequence to cover everything below it, or ask for no acks at all when fire-and-forget is what you meant.
Key-value buckets
A bucket is a stream that keeps the last value per key, so you get watches, per-key history and expiry from the same server and the same connection. It is where Hanzo Stream keeps its consumer offsets.
Request-Reply
Send to a subject and wait for one answer. Put several instances of a service in a queue group on that subject and each request goes to exactly one of them — load balancing with nothing in front of them doing it.
Object Store
Payloads too big to be a message are chunked into a stream and put back together on the way out, with a watch for when one changes. Same connection, same credentials, no second system to stand up.
Accounts, not passwords
An account walls one tenant's subjects off from another's. Credentials are nkeys or signed JWTs rather than a shared secret, permissions are granted per subject, and TLS covers the wire.
Publish and Subscribe
nc, _ := nats.Connect("nats://pubsub.hanzo.ai:4222")
js, _ := nc.JetStream()
// Create a durable stream
js.AddStream(&nats.StreamConfig{
Name: "EVENTS",
Subjects: []string{"events.>"},
Storage: nats.FileStorage,
Replicas: 3,
})
// Publish
js.Publish("events.user.signup", []byte(`{"id":"usr_123"}`))
// Durable consumer with ack
sub, _ := js.PullSubscribe("events.>", "my-service")
msgs, _ := sub.Fetch(10)
for _, msg := range msgs {
process(msg.Data)
msg.Ack()
}Up to 5% of compute goes back to open source
Every deployment is SBOM-verified. Contributors to NATS JetStream earn a share of compute revenue — transparent, on-chain, and customizable by the community.
Up to 5% of compute goes back to OSS authors
Every Hanzo deployment tracks software dependencies via SBOM. When your code powers compute on Hanzo, the authors get paid — automatically.