[panarky]

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?

[imslavko]

You can also paginate by `$gt` and `$lt` operators. For example, if you have a list of posts, they are probably displayed in some order on the screen. Most likely they are ordered by date. You can maintain the pagination by presenting all posts older than X but newer than Y.