Highly related https://stackoverflow.com/questions/6021938/nodejs-many-clients-requests-through-one-socket

I'm investigating a robust message passing system for this application of mine. The easyest solution would be Redis pub/sub (it's simple, effective and I'd also use Redis for caching) but as I understand it, publishing is a "one shot" operation only to actually subscribed clients. Whoever subscribes after the publishing, does not get the message. I'd like to be able to "stash" unreceived messages for a while, so if I reconnect to the channel I'd get back the messages I've not received. I know that systems like ActiveMQ with the ack and permament queue mechanism would solve this issue easily, but I'm wondering if there could be a simpler solution/approach. What do you think?

2 Answers 2


use a second permanent database. Use redis for real time sending of messages through pub/sub but also store all your messages in a permanent database (couch / mongo).

Then when a Client / User reconnects load all messages from the real database and put them in the redis pub/sub system.

You will need this anyway to implement a history / past events system.

  • but then that's not pubsub is it?
    – jcolebrand
    May 19, 2011 at 15:14
  • @drachenstern >_< It's both. He wants a new user to get previous data that was published before he subscribed. The best way to do this is from a queue / stack. The best way to implement that is a permanent storage database.
    – Raynos
    May 19, 2011 at 15:27
  • Yes, it is (in theory) - because the idea is that messages will be re-published on the channel. It won't work anyway, because someone should know which messages have to be popped from the database. We have not this info, beacuse there is no ACK mechanism...
    – Claudio
    May 19, 2011 at 15:29
  • Which is no longer pubsub. I'm just saying I think there's a better mechanism in place to do what he wants already, or at least an existing pattern that's better than pubsub. The folks at P.SE tend to be more knowledgeable about patterns than we (or at least are faster to respond with them). I honestly feel he's asking for Atom/RSS
    – jcolebrand
    May 19, 2011 at 15:30
  • @Claudio store a message received flag in the database for all users :D
    – Raynos
    May 19, 2011 at 15:30

You could do this easily with CouchDB. It has a /_changes API that gives you a running history of changes. You can give it a timestamp to get everything since then.

If that doesn't work, you could make a simple queue and save messages yourself. It doesn't have to be the fastest because they are archived.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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