BunnyMQ: Best Kafka-Compatible Brokers for Go Developers in 2026

What Is BunnyMQ?

BunnyMQ is a Kafka-compatible distributed message broker written in Go by the BunnyMQ project on GitHub, and it is one of the best Kafka-Compatible Message Brokers tools for Go developers, backend engineers, and platform teams. It targets three-or-more-node clusters, serves topics, partitions, and consumer groups over gRPC + Protobuf, and uses dragonboat Multi-Raft for replication.

BunnyMQ is built for teams that want a readable broker implementation instead of a black box. The page shows a live 3-node topology, explicit leader routing, and a CLI that can create topics, produce messages, and consume them with offset control.

Quick Overview

Who Should Use BunnyMQ?

BunnyMQ is a good fit when you need a broker you can inspect end to end and run on a small controlled cluster.

• Platform teams building internal event infrastructure — BunnyMQ gives you broker state, Raft leadership, and partition handling in a Go codebase that is easier to reason about than a large JVM system.
• Backend engineers shipping event-driven services — BunnyMQ supports topic, partition, and consumer group workflows, so you can model ordered streams without inventing a custom queue layer.
• Indie hackers and infra tinkerers — BunnyMQ is practical for experimentation because the repo includes docker-compose cluster startup, native three-process startup, and a purpose-built CLI.
• Teams validating replication semantics — BunnyMQ is useful when you care about acks=0 and acks=all, partition leadership, and commit-offset behavior more than broad ecosystem compatibility.

Not ideal for:

• Teams that need the full Apache Kafka protocol surface and its mature client ecosystem.
• Single-node apps that do not want to operate a Raft quorum and persistent log files.
• Projects that require advanced broker features like transactions, tiered storage, or compacted topics, because the page does not document them.

Key Features of BunnyMQ

• Multi-Raft replication — BunnyMQ uses dragonboat to split the cluster into multiple Raft-managed state machines. The architecture separates metadata handling from partition data handling, which keeps cluster coordination and hot-path writes from fighting over the same lock domain.

• Kafka-style primitives — BunnyMQ exposes topics, partitions, consumer groups, and offset commits. That is enough to build ordered stream processors, worker pools, and replayable event feeds without inventing a bespoke consistency model.

• Leader-aware routing — Group RPCs such as JoinGroup, Heartbeat, LeaveGroup, and CommitOffset are served by the metadata-shard leader, while produce and fetch requests are served by the partition-shard leader. If a client hits the wrong node, BunnyMQ redirects automatically.

• gRPC + Protobuf wire protocol — BunnyMQ does not hide its API behind a generic JSON surface. The broker uses typed RPCs and generated protobuf messages, which is cleaner for Go clients and easier to extend than ad hoc request parsing.

• Segmented append-only storage — The data path writes to an append-only log that is segmented on disk. That layout is a natural fit for sequential I/O, recovery after restarts, and offset-based reads, especially when paired with retention rules like retention-ms and retention-bytes.

• Operational CLI — bunnymq-cli handles topic create/list/describe, partition expansion, retention changes, produce, consume, and cluster inspection. For local workflows, that matters more than a pretty dashboard because it turns the broker into something you can script in CI.

• Prometheus and pprof hooks — The broker exposes metrics on {METRICS_ADDR}/metrics and supports a pprof endpoint when configured. That makes it easier to inspect latency histograms, per-partition throughput, and runtime pressure during load tests.

BunnyMQ vs Alternatives

Pick BunnyMQ when you want to study broker internals, control the replication model, or build a compact internal event system. Pick Kafka when the ecosystem matters more than code readability or minimalism.

Pick Redpanda when you want Kafka-style semantics with a commercial support path and a more opinionated operational model. Pick NATS JetStream when your workload leans toward lightweight messaging, service fanout, or request/reply rather than strict partitioned log processing.

If BunnyMQ is part of a larger platform rollout, pair it with OpenTrace for tracing consumer latency and DataHaven for persisting derived data outside the hot path. For deployment automation around the cluster itself, djevops fits the same operational workflow.

How BunnyMQ Works

BunnyMQ splits responsibility across distinct coordinators instead of collapsing everything into one monolithic broker loop. The page shows a ClusterCoordinator, GroupCoordinator, MetadataFSM, DataCoordinator, PartitionFSM(s), and Storage layer, all backed by dragonboat Multi-Raft and accessed over gRPC on separate management and data ports.

The design choice that matters most is the split between metadata leadership and partition leadership. Group membership and offset commits are handled by the metadata shard, while produce and fetch operations are handled by the partition shard, which keeps control-plane updates from competing directly with hot data-path requests.

The storage model is a segmented append-only log, which is the right choice for a broker that wants predictable writes and cheap recovery. The architecture also assumes a real cluster, not a toy local daemon, so the happy path is three or more nodes with explicit INITIAL_MEMBERS and persisted DATA_DIR state.

make cluster-up
bunnymq-cli --brokers localhost:19091,localhost:29091,localhost:39091 topic create --name orders --partitions 3 --replication-factor 3
printf '{"id":1}\n' | bunnymq-cli --brokers localhost:19091,localhost:29091,localhost:39091 produce --topic orders --acks all
bunnymq-cli --brokers localhost:19091,localhost:29091,localhost:39091 consume --topic orders --group api --count 1

This flow builds a 3-node cluster, creates a replicated topic, writes one record, and reads it back through a consumer group. If the request lands on a follower, BunnyMQ handles leader redirect, so the client does not need to guess which node owns the partition.

Pros and Cons of BunnyMQ

Pros:

• Clear broker architecture — the page exposes the major FSMs and coordinators, which makes the system easier to audit than a black-box service.
• Go implementation — the broker is written in Go, so teams that already ship Go services can inspect, modify, and instrument it without crossing language boundaries.
• Explicit replication model — dragonboat Multi-Raft gives BunnyMQ a real quorum story instead of pretending one process is enough for durability.
• Good local developer experience — docker-compose cluster startup, native three-process startup, and bunnymq-cli make testing straightforward.
• Operational visibility — Prometheus metrics, optional pprof, and structured logging are all present in the repo text.
• Useful retention controls — topic retention can be set by time or bytes, which is enough for many internal streaming workloads.

Cons:

• Needs a multi-node cluster — the architecture is aimed at three-or-more-node deployments, so it is a poor fit for single-node convenience.
• Protocol surface is narrower than Kafka — the repo describes gRPC + Protobuf RPCs, not the full Kafka wire protocol or client ecosystem.
• Feature set is still small — the page documents acks=0 and acks=all, but not transactions, compaction, or tiered storage.
• Operational setup is manual — you need to manage Raft addresses, node IDs, data directories, and initial membership carefully.
• License and release metadata are not stated on the page — that makes adoption checks slower for companies with procurement or compliance gates.

Getting Started with BunnyMQ

The fastest path is the docker-compose cluster because it hides the Raft bootstrap details and gives you a working 3-node setup immediately.

git clone https://github.com/bunnymq/bunnymq
cd bunnymq
make cluster-up
make cluster-logs
bunnymq-cli --brokers localhost:19091,localhost:29091,localhost:39091 topic list

After that, create a topic, send a message, and consume it through either manual mode or group mode. If you want native execution instead of Docker, export NODE_ID, RAFT_ADDR, MGMT_ADDR, DATA_ADDR, METRICS_ADDR, DATA_DIR, and INITIAL_MEMBERS before launching each broker process.

For production-like testing, the native mode is useful because it forces you to think about persistent directories, stable Raft addresses, and quorum membership. For quick evaluation, the compose cluster is enough to validate topic creation, partition leadership, and consumer group assignment.

Verdict

BunnyMQ is the strongest option for teams validating a Kafka-style broker in Go when they want inspectable internals and Multi-Raft replication more than ecosystem depth. Its biggest strength is the split metadata/data leader design. The caveat is the 3-node quorum requirement and the narrower protocol surface. Use it for infrastructure experiments and internal pipelines, not Kafka migration work.