Redis-Oplog has become very stable at this point, backed up by all sorts of tests. (Not labeling it prod-ready yet)
After I'm finished with this my objective is to show to the world how scalable Meteor is in fact.
Wish I had time to show you how much improvements can redis-oplog give you. Some other guys that took the same approach with the oplog https://github.com/chatr/redpubsub
This all works well at Chatra. Performance improved to a point where we no longer worry about performance (not any time soon at least). Right now ≈300 active sessions give about 5% CPU usage on a single machine, before this implementation ≈150 sessions cost us about 75% of CPU.
Keep in mind this is not just 30x improvement. It is much more and it exponentially increases as your active sessions increase. This is what you would gain if you use "channels" for communicating changes with redis-oplog.
So why not use their package ? Well I found a bit too late about their package, + redis-oplog package aims to make it BC with Meteor + it already has many other features
There is a key feature left. A feature that will shake the industry of real-time. I'm talking ofcourse about "Sharing Query Watchers across Meteor Instances"
I can now confirm 100% that this is an achievable task. It's now just a matter of time and finding the right approach and figuring out the edge-cases and make it absolutely fail-safe. We will have the ability to specify which queries we want share-able, because ofcourse the sharing will have a small overhead, sometimes it may not be a good idea when you are dealing with mostly unique publications.
I am scrapping my thoughts about in this google doc. Feel free to leave comments.