Anyway, this is a nice architecture indeed.
However, as a pure proxy, I would think nginx would be more appropriate for its (albeit poor but swappable) load balancing, rate limiting (a 3rd-party module), caching (memcache, redis), and general volume of usage.
In fact, there's the beginnings of a nginx upstream based redis module that supports redis' GET that could be made to RPUSH and BLPOP the result.
FWIW, I'm the author of redis-node-client. It should be noted that Promises were removed in favor of continuations in the latest Node.js on Github and I've updated redis-node-client appropriately. Thus, the sample code in the article is outdated by 2 days or so.
Using LPOP in a polling loop to wait for the response is not that great of an idea. It would be better to use BLPOP or "blocking left pop" which blocks the client connection (think "long polling") until there's something in the given list to pop. It does not waste resources and the results are returned in much less than the worst case (e.g. 100ms here). I haven't added BLPOP to redis-node-client yet though but it should be simple to patch.
To scale this beyond a single frontend, popFromQueue could potentially put the response back via LPUSH when the queuedRes[requestNumber] is nil... "Oops, this wasn't for me, let me put that back." Or, it could/should use something more formal.
Why does the Ruby worker shell out to redis-cli instead of using Ezra's client library?
Finally, "The previous spike..." What does "spike" mean here?
For pure proxies, there are definitely more appropriate tools. However, this gave me a chance to play with node.js. And I may develop it into a more full featured proxy.
I haven't seen the new continuations stuff in node. I will have to check it out.
BLPOP looks great. I will check it out.
I've thought a little about scaling to multiple frontends. I thought multiple response queues might be the easiest. Along with a request number, the node server could tell the backend which response queue to use.
I shell out to redis-cli purely for ease of development. I was already familiar with the cli, so I used it. I will definitely switch to a real redis library if I continue developing.
And finally, I used the term spike to mean a non-production quality programming exercise to prove out the solution at a high level. See http://c2.com/xp/SpikeSolution.html for more details.