The main reason, while there certainly are others, for hitting an oplog flooding problem would be when your app does rapid database operations, especially with
multi: true mutations.
I’ll go ahead and further speculate that you’ll have control over such situations thus provide means to throttle them. Eg, hourly updates on some counts that you store on your users collection where you have 10000 users. You might instead want to update them in batches of say 100 and 30 seconds apart.
Other examples would be cases where you update references to demormalized data, eg a user’s username as it changes on 2000 comments where it was denormalized along with the userId. You’d then rethink why and how you denormalize the data and whether realtime (and perhaps non-reactive) lookups (joins) would perhaps be a better idea.
Therefore, you should go over the design of your application at this point. That coupled with meteor’s latest fix as suggested above would keep you sleeping well over these coming nights until there is an even better fix and support for things like shards.