So with oplog tailing, I can scale by adding multiple Meteor processes behind a reverse proxy with sticky sessions.
It seems that since oplog tailing doesn't work with a sharded database, then each additional Meteor process must also tail the entire oplog and evaluate all transactions for all Meteor processes.
How does this work for a site with, say, 100 transactions per second and a dozen subscriptions to observe? Does it saturate the Node event loop, or are there plenty of ticks left for the application?
And if I use 'skip' and 'limit' to page through large result sets, it looks like oplog tailing isn't an option. Is there a better way to keep the client data small and take advantage of oplog tailing?