vs RabbitMQ
RabbitMQ is a mature, widely-deployed message broker built around the AMQP protocol. It models messaging through exchanges, queues, bindings, and routing keys — a flexible but more complex abstraction than simple pub/sub.
Use RabbitMQ when
- You need guaranteed at-least-once delivery with durable queues that survive broker restarts.
- You need sophisticated routing: topic exchanges with routing keys, direct exchanges, headers-based routing, or dead-letter queues.
- You need acknowledgements, nacks, and message requeue on failure.
- You have teams already familiar with AMQP and existing RabbitMQ tooling.
- You need the management UI for operations visibility and manual queue inspection.
- You need plugins for delayed messages, federated queues, or Shovel.
Use tinybroker when
- You want a simpler mental model: topics, patterns, subscribe, publish. No exchanges, no bindings, no routing keys, no queue declarations.
- You want a gRPC interface with generated typed stubs rather than an AMQP library. This is particularly useful when all your services already use gRPC for inter-service calls.
- You do not need durability — messages can be lost on restart, and the simplicity that comes from no persistence is worth it.
- You are deploying in a Kubernetes environment where RabbitMQ’s StatefulSet, PersistentVolumeClaim, and operator management add complexity you would rather avoid.
- You want a sub-10 MB container image with no Erlang runtime dependency.
The core trade-off
RabbitMQ’s AMQP model is powerful and flexible but requires understanding exchanges, bindings, and queue durability settings before your first message is delivered correctly. tinybroker’s model is: publish to a topic name, subscribe with a pattern, done. The trade-off is all the features RabbitMQ provides on top of that simplicity.