I'm building a system using redis as a pub-sub system.

I'm thinking about ways to represent multiple groups that clients can subscribe to. I could do this with one channel per group, but this could lead to a vast number of channels on the redis side and multiple subscriptions from each channel.

Alternatively, I could put a group identifier in my messages. Each client would have a single subscription to a channel for all groups. Clients would get all messages and do their own filtering.

"Privacy" is not an issue here; it's ok for clients to see messages they don't need.

So: are there any considerations for redis servers or clients that should lead me to favour one approach over the other?

FWIW, my clients are nodejs clients.


I think the channel approach is preferred over a group identifier. Clients should only subscribe to messages that are actually important to them. While this may lead to a lot of Redis channels and connections, the alternative would create very chatty subscriptions where messages are being sent to subscribers but immediately discarded because they don't have the right group identifier. If you have clients that have expensive/limited bandwidth (i.e. mobile devices) it would negatively impact your client to receive pointless messages.

Redis doesn't have hard limits on the number of channels--it's limited by the number of connections it can maintain. I've read that the number of connections can be scaled out with master/slave replication. If you end up scaling beyond what is reasonable with Redis, I would migrate to one of the many pub/sub paid services.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.