NATS JetStream

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.

GitHub

Paste and ship

Paste this into any agent. It reads the skill manifest and calls Pubsub from there.

Agent prompt

Read https://hanzo.ai/skill.md and use Hanzo Pubsub in my project. Start with: hanzo pubsub publish

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.

4222

Client port

Replay

From any point

Durable

Written to disk

Replicas

Set per stream

Publish and Subscribe

events.go

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()
}

Open source royalty

20% to the author of the code that runs

Verify that you own a repository, and every org that deploys a project built from it pays you 20% of its metered spend, accrued each period.

How authors are paid Our repositories

Put it between your services

Free tier includes 1M messages/month.

View on GitHub

Start building with Pubsub

Get your API key

One API key. One credit balance. Every primitive.

Open source

License: Apache-2.0hanzoai/pubsub

Get PubSub

Pub/sub messaging

Deploy to Cloud