The table approach would still work: a subtask you need to solve is how
to allocate a unique URL to a bunch of user ids and then redirect them
to the new URL when the timeout expires.
function, if it's not critical for the users to wait for 10 seconds to
be redirected to the right URL.
If it's very critical to redirect users quickly and waiting 10 secs is
too long, you can try 5 secs. You could also explore the approach of
implementing a push mechanism (I guess you can read discussions like
to get you started). Choosing between the two is a tradeoff of 1) how
much time do you want to spend coding/researching the topic, 2) what are
the actual user requirements for your app, 3) how much load would the
Thanks Martin and Colin.
With your help and reading some stack overflow posts i’ve arrived at a solution that meets my need best. I’m posting it here so that it might be useful for other users.
Since I wanted the users to be redirected in real time to a URL chosen by the admin or an algorithm in real time. I needed a solution that could push updates from the server to browser. Also sometimes, accompanied by events from the browser that may be relayed to other browser.
The status quo presents three approaches:
Nodejs server + Redis + Socket.io- The following blog post has all the details and was incredibly useful. http://liamkaufman.com/blog/2013/02/27/adding-real-time-to-a-restful-rails-app/
Server Sent Events and Ajax: The following post by the creator of Juggernaut explains how useful SSE could be and the reason why he killed Juggernaut. http://blog.alexmaccaw.com/killing-a-library
I started with the first option (Nodejs) after hearing a ton of good things about it. But finally realized that running Redis, Nodejs, Rails and Socket.io would be an overkill. A complicated solution. I also read about hosting issues with Socket.io on heroku. Although I use Amazon Ec2, i didn’t wanted to take a chance.
I decided against SSE because they are not supported Internet Explorer. Moreover unlike websockets they are half duplex and thus might not be the best approach to implement presence, chat rooms or any other application that requires full duplex communication.
I finally decided on using the third alternative. Pusher, although being a paid option has a sandbox plan that suits my current needs. Moreover, it has great APIs for implementing realtime presence which greatly suits my purpose. The documentation is very easy to follow as well.
I hope this helps someone in the future.