Raising maxPoolSize vs tuning maxIdleTimeMS for intermittent MongoDB pool exhaustion

An application using the official MongoDB driver intermittently fails to acquire connections under bursty load, even though average concurrency stays well below the configured maxPoolSize. Pool monitoring shows the connection count shrinking during quiet periods and then failing to grow back fast enough when traffic spikes, so some requests appear to wait or fail rather than being served from warm idle connections.

The two documented levers seem to conflict. Increasing maxPoolSize raises the ceiling but does nothing if idle connections are being evicted before the burst arrives. Lowering or removing maxIdleTimeMS keeps connections warm, but risks holding stale connections across failovers and consuming server-side resources. The maxConnecting limit may also throttle how quickly the pool can regrow after eviction, but its interaction with idle eviction timing is unclear.

Assume a recent driver version (e.g., Node.js 6.x or Java 5.x); behavior may differ across implementations.

• For burst-after-idle workloads, is it better to disable maxIdleTimeMS eviction or to size maxPoolSize and maxConnecting for fast regrowth?
• Is idle eviction timing relative to maxIdleTimeMS guaranteed anywhere in the driver specification, or is it implementation-defined?
• Which pool metrics or log events best confirm eviction timing versus acquisition queuing as the root cause?