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?
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.
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.