This is super interesting, I have a very similar project that we use at Discourse <a href="https:&#x2F;&#x2F;github.com&#x2F;SamSaffron&#x2F;message_bus" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;SamSaffron&#x2F;message_bus</a> clearly being an NGINX module nchan is going to be a LOT faster<p>That said there are few little pointers that would make integrating MessageBus with nchan a bit challenging<p>- We have a concept of &quot;reliable pub sub&quot; <a href="https:&#x2F;&#x2F;github.com&#x2F;SamSaffron&#x2F;message_bus&#x2F;blob&#x2F;master&#x2F;lib&#x2F;message_bus&#x2F;redis&#x2F;reliable_pub_sub.rb" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;SamSaffron&#x2F;message_bus&#x2F;blob&#x2F;master&#x2F;lib&#x2F;me...</a> this means that if you shut your laptop and then open it stuff just magically catches up with no loss of messages or ordering. Does the redis store you have do something similar (I can not see backing lists in the redis store implementation in store.c)<p>- We implement per-message security, meaning you can publish to a channel&#x2F;group or channel&#x2F;user and only those users get the message, I see you can do auth upfront but can per-message security seems not doable.<p>- We don&#x27;t bother with per-channel URLS and instead just have a single endpoint you multi-subscribe using POST params, we often subscribe to 10 channels on a request, the multiplexing seems a bit limited<p>- When we subscribe to a channel due to the &quot;reliable&quot; nature of the store we are able to tell the server what the last id is we subscribed to and catch up from there<p>I definitely see us moving the moving our message bus server piece closer to the web server like nchan has, its by far the most scalable way, but its tough keeping feature parity.