Single-node · In-memory · gRPC

Heads up: I ended up switching to NATS + PostgreSQL. If you need consumer groups, bare NATS won't help — you need JetStream, which requires persistence. tinybroker fills the gap when you want in-memory consumer groups with no persistence overhead. The code works and is free to use; just know why you're reaching for it.

vs Redis Pub/Sub

Redis Pub/Sub is a simple fan-out messaging feature built into Redis. It is often the first tool teams reach for because Redis is already deployed as a cache.

Use Redis Pub/Sub when

  • Redis is already in your stack and adding a new service is not justified.
  • You only need fire-and-forget fan-out with no delivery guarantees.
  • You need the simplicity of a single PUBLISH command and SUBSCRIBE / PSUBSCRIBE in a Redis client your team knows.
  • Message volume is low and the shared Redis instance has spare capacity.

Use tinybroker when

  • You want consumer groups with balanced delivery. Redis Pub/Sub is strictly fan-out — every subscriber receives every message. For work-queue behaviour (each message to exactly one consumer), you would need Redis Streams, which is a fundamentally different API and data model.
  • You want a dedicated, isolated messaging service that does not compete for memory and CPU with your cache. A Redis instance under cache pressure may start evicting pub/sub connections or dropping messages.
  • You want a strongly-typed gRPC interface rather than raw Redis protocol. Generated stubs enforce message structure; Redis Pub/Sub payloads are untyped byte strings.
  • You need dynamic wildcard patterns evaluated per-message. Redis PSUBSCRIBE supports basic glob patterns but evaluates them at subscribe time against channel names, not per-message as topics appear dynamically.
  • You want explicit consumer group semantics (BALANCED, SINGLETON) with acknowledgements. Redis Streams provide this but require a different API and command set, adding cognitive overhead.

Summary

Redis Pub/Sub is convenient when Redis is already present, but it is a secondary feature of a caching system — not a first-class messaging broker. When coordination between replicas becomes a meaningful part of your architecture, a dedicated broker with clear semantics is cleaner than repurposing a cache.