By not using it 
There will be lots of ways to skin it, from least amount of work to most performance. Iāll be able to give you a better idea once I can try out different combos.
The easiest solution should just work with a simple adapter in the publication.
Yeah, thats pretty intense stuff. Idk half the stuff heās talking about though! Iād really like a one-size-fits-all scaling solution though 
Specifically, I want to be able to scale a service like facebook or instagram ā a follower network.
Interesting video. Note that they mentioned in the video there is very little traffic between nodes. The secret sauce appears to really be Mnesia, which looks very much like a built-in Redis but with a fixed schema instead of a key-value store.
When trying to scale horizontally something thatās key to remember is Amdahlās Law.
Think of it like a restaurant with a single cook. No matter how many waitresses you add the system will only be as fast as the cook.
With stateless rest each waitress essentially has her own cook. When you need to share state across nodes, whether your backplane to share state is configured as a database or Redis memcache that will always be your limiting factor no matter how many nodes you add.
The good thing is you can scale Redis sky high. If you can shard your data you can scale it even higher! The best practise always is splitting your application into functional groups/sets and scaling them individually. Thatās why microservices work so well in Rest land.
In your chat example that might be sharding by particular rooms. In Hansoftās solution, that would be grouping writes by tenant.
In both examples the hard work is moved out of the event loop onto a separate application. Rule #1 in node is to not block the event loop. Meteor is not only violating that rule but calling it a feature. In MDGās restaurant the waitress is also the cook. Good luck getting that burger during lunch rush!
You want to look into a graph database like Neo4j.
Would it be possible to create some package (or maybe in the core) that will make a subscription works in 2 different modes:
The second one would be used for complex queries with lot of parameters were the oplog parsing isnāt efficient.
This would be very easy to do without a package too :
Template.X.onCreated(function () {
this.pollingIntervalId = Meteor.setInterval(function() {
Meteor.call('getCustomData', function (err, data) {
if (!err) LocalCollection.upsert({_id: data._id}, data);
}
}, 5000);
});
Template.X.onDestroyed(function () {
Meteor.clearInterval(this.pollingIntervalId);
});Does anyone know if thereās a way to cache the HTML page going down to the client? (basically the view source version). This is becoming a bottleneck in my setup. With load testing a 2GB box can only handle ~400 concurrent users before it starts spewing errors. This is without executing JS (need a better load tester). I can get to ~800 users but at that point itās throwing hundreds of errors.
Iām considering moving the initial HTML to a CDN (Cordova style connection), perhaps that would be the easiest at scale.
Yep, iāve done something similar to #2 with pretty good success. The only issue is this is essentially long polling with ajax. Gets the job done though!
Yes, you can have a query with oplog disabled and return it to the subscription, like described here:
Meteor.publish("comments", function (postId) {
return Comments.find({post: postId}, {_disableOplog: true, fields: {secret: 0}});
});Just wanted to recap some info here, You can actually serve the meteor page over a CDN with some config, I think joshowens is writing a blog post about this! Also he suggested using mupx with page caching turned on as an alternative.
I canāt find any docs on mup/mupx āpage cachingā feature, whatās it do?
I think itās specific to nginx:
https://www.nginx.com/resources/wiki/start/topics/examples/reverseproxycachingexample/