I think you might be confused as to what Pub / Sub really is in Redis. This is not a way to listen for hash changes; you can have a Pub / Sub channel named sellers-1 , and you can have a hash with the sellers-1 key, but they are not related to each other.
As described here :
Pub / Sub has nothing to do with key space.
There is a thing called key notifications , which can be used to listen for changes in key space (via Pub / Sub channels); however, this feature is not enabled by default because it will require more resources.
Perhaps a simpler way would be to post a message after the HMSET so that any subscribers know that the hash has changed (they would then retrieve the contents of the hash themselves, or the published message would contain the relevant data).
This leads us to the next possible problem: you only have one connection for subscribers, redisSubscriber .
From what I understand from the Node.js Redis driver, calling .subscribe() on such a connection will delete any previous subscriptions in favor of the new one. Therefore, if you have previously subscribed to sellers-1 and subscribed to sellers-2 , you will no longer receive messages from sellers-1 .
You can listen to several channels by passing an array of channels or passing them as arguments:
redisSubscriber.subscribe([ 'sellers-1', 'sellers-2', ... ]) // Or: redisSubscriber.subscribe('sellers-1', 'sellers-2', ... )
You will obviously have to track every “active” seller’s subscription. Either this, or create a new connection for each subscription, which is also not ideal.
It is probably best to have one Pub / Sub channel on which all changes will be published, rather than a separate channel for each seller.
Finally: if your seller ID is not hard to guess (for example, if it is based on an incremental integer value), it would be trivial if someone wrote a customer who could listen to any seller they would like. This may not be a problem, but it is something to be aware of.