Meteor server MongoDB pool exhaustion under subscription load: oplog vs polling and observer duplication

A Meteor application backed by MongoDB intermittently stalls under load: requests time out and the server appears to hang, with symptoms correlating with the number of active DDP subscriptions rather than raw query volume. The goal is to diagnose whether the exhaustion comes from the MongoDB driver's connection pool being saturated by server-side observe handles, and to decide on the right corrective direction.

Relevant constraints: Meteor opens MongoDB connections through the bundled Node MongoDB driver, so pool sizing (e.g., maxPoolSize) is set via driver options on the connection string, not a Meteor-specific API, and defaults vary with the driver version pinned to the Meteor release in use. Oplog tailing via MONGO_OPLOG_URL is supported but requires replica set oplog credentials that some managed MongoDB tiers do not expose; without it, Meteor falls back to poll-and-diff, which issues repeated queries. Observe handles for similar queries may not be multiplexed across clients when publications differ in selectors or options, and reconnect storms or hot code pushes can spike observer creation.

Given that, the open questions are:

• How can pool checkout counts and wait-queue depth be captured at symptom time to confirm the driver pool is the bottleneck rather than publication CPU?
• How should observer duplication be measured per publication to determine whether multiplexing is failing?
• Should the fix prioritize restoring oplog access, tuning the polling interval/throttle, or enlarging the pool, and how can each be verified independently?