Every oplog change hits every Meteor instance creating an exponential scaling problem.
I know that some companies already has written custom pub/sub systems to communicate between Meteor processes. One of the solutions to make it work through Redis channels. Another one it to use third-parties (pubnub.com for example).
Who has already faced this problem? Or tried to write something for that? Or made a research? Do we have opensource projects? How to run away from oplog? Let’s discuss 
An idea that was in the air for a long time was to write more specialized oplog proxies.
So you would have multiple server types, each having the same business logic but they will be responsible only for publishing queries for particular collections.
Then you can write a separate oplog proxy that only emits oplog records for that collection and ignores a big traffic of irrelevant messages.
From what I’ve seen, there are virtually no solutions other than reducing the number of database operations. It would be a hell of a project though, and I would pay money for a supported package that can implement what Slava is suggesting
Signed! This would be a useful service for more than Meteor also.
In theory and not super big scale you can already architect instances layout in a way when every reactive collection is in separate database, put meteor instance above it and provide DDP method which will feed you information based on variable query.
Than in another server instance you can DDP.connect, create collection, subscribe and than query it as you want.
Example: http://stackoverflow.com/questions/23797695/how-to-subscribe-via-ddp-connections-to-other-meteor-servers-on-the-server-side
I would expect if you connect like it in server startup, in server method you can just return cursor above that given collection which represent cursor above remote collection.
Still it would probably lag few seconds so not true realtime expirience.
But for scaling user facing instances it seems like something I would try if I need it 
So I dont feel there is some special separate package needed - just strip collections to separate databases, put meteor instances above them.
And in your standard meteor instances replace local collections with remote ddp connect + collection + subscribe.
Sounds easy in theory, any1 tried it, what was the issue?
And I am going back to learning neo4j, cause I love relations
At Nodechef, we introduce both Query Tailing and Oplog filters for scalability.
Query tailing works by allowing you to subscribe for changes on any mongoDB query, and its utilization in any application is analogous to tailing a capped collection. Query tailing is implemented outside of the meteor app and utilizes database indexes to continuously process the client query. Query tailing is implemented using a reverse index tactic which registers a listening client based on the shape of its query to an index. Evaluating what each client sees when a document is inserted or deleted in many cases results in a single hashtable lookup. This significantly eliminates the CPU bottleneck in meteor apps having to inspect each oplog entry and also in some cases round trips to the database to read more document fields.
The second approach is Oplog filters. Oplog filters utilizes shares exactly the same architecture as query tailing with the only difference been the changes are emitted to the local.rs.oplog collection instead of a listening client. With this approach developers do not have to change a single line of code. The meteor app only receives oplog entries which will be of interest it.
Many other interesting features we will be adding in the platform. Check us out here: http://nodechef.com/features
Ask me anything about scaling.
Everything does exist and the platform will be available for testing in a matter of weeks. Stay tuned. If you have any specific questions about scaling meteor apps, I’m available to answer them.
Still would like to see metrics.
+1
I’d even think about open sourcing whatever powers this - could be a great marketing move.