Notable Deed
Narad
A message broker in one Go binary.
A message broker that respects your weekend: plain HTTP in, at-least-once out, and nothing to babysit in between. Built to learn distributed systems properly, then soaked, crashed, audited, and drilled until the evidence caught up with the design. v1.0 shipped in July 2026, rebalancing arrived in 2.0, and Narad 3 added batches and copies across clusters. It’s on v3.2.2 now; the forge is still lit.
Enchantments
Durable before acknowledged
A 202 means the message is fsynced to disk, not buffered, not "probably". Crash a millisecond later; it survives.
Built to say yes
Availability first: any live node accepts your produce and routes around dead partition owners. Machines burn; messages land.
No consumer groups
No rebalancing storms, no generation IDs. Scale consumers by starting more consumers; that’s the whole runbook.
Plain HTTP, any language
The whole API is HTTP, described by an OpenAPI spec. There’s a Go client if you want one; curl works if you don’t.
Batches when you need speed
Send up to 1,000 messages in one request, read and ack up to 100. One disk flush carries the whole batch.
One topic, many copies
Attach child topics and every message is copied to each: right away, after a fixed delay, or onto other servers as a replica.
Copies across clusters
A remote child copies a topic to another Narad cluster as messages arrive: offload a busy topic, or keep a recovery copy in another region.
Schemas at the door
Give a topic a JSON Schema and a bad message gets a 400 naming the field. Nothing malformed ever reaches the log.
Grows and shrinks under load
Add servers, rebalance partitions, or drain a node before removing it, without pausing producers or losing a message.
Least privilege
Give each service its own user with only the grants it needs, like produce on orders-*. Every change is written to an audit log.
Nothing hidden
Prometheus metrics for everything, ready-made alerts for what really goes wrong, and a troubleshooting guide that starts from the symptom.
One binary, one Helm chart
Raft lives inside the same binary. No ZooKeeper, no keeper of any kind. If you can run a StatefulSet, you can run Narad.
Proven in the Field
376k/s
messages in batches of 100 on three nodes, sustained through send, read and ack
135M
messages in that run, each one checked off; none missing
0
messages lost across every chaos run: leader kills, all-node kills, network splits
10.5k/s
sends on a single 2-CPU node, one message per request, up from 5.6k in August
300M+
messages soaked through the 1.0 release on a live five-node cluster
44.8M
messages in the September soak, none left undelivered
101
confirmed problems fixed from two code audits of the busy path and the control plane
Passing
OpenSSF Best Practices badge, with security reporting, testing and release rules
Plus a remote child that copied 320,211 records to another cluster in about six seconds and lost nothing through node kills, a dead target cluster and a 60-second network split; a linearizability checker that ties every redelivery to a fault; a chaos matrix ofkill -9s and mid-write restarts; and rolling upgrades with written rollback rules, all against a real Kubernetes deployment, not a laptop.
The Honest Fine Print
Narad stays small on purpose. Ordering is not guaranteed (carry a sequence in the payload if you need one). Each partition is stored once, so a lost disk loses what’s on it unless you keep a replica child or volume snapshots. There’s no retry engine, dead-letter queue, message headers or duplicate detection in the broker; you build those from topics, leases and acks, and the docs show how. Client TLS ends at your ingress. The docs say all of this in bold, not in a footnote.
The Quest Chain
The build is chronicled in 8 journal entries, from the first sketch to Narad 3: