MongoDB Pool Saturation vs Traffic Burst, MongoDB

​

At a glance

A cross-channel table that puts MongoDB connection-pool saturation side by side with the storefront traffic burst driving it, so you can tell, in one view, whether a saturation spike is “real demand we need to provision for” or “a client leak that has nothing to do with shoppers”. Each row pairs a short time slice with both signals: the pool saturation percentage on the database, and the corresponding storefront traffic from the connected ecommerce platform. The card turns red when saturation runs >90% during a traffic burst, the combination that most often precedes a checkout-impacting outage during a sale.

​

Calculation

Database series (per 15m window):
  pool_saturation_pct = connections.current
                        / ( connections.current + connections.available )
                        x 100        (from serverStatus.connections)

Storefront series (same 15m window):
  traffic_burst = storefront sessions / requests per window
                  from the linked ecommerce connector

Alert condition:
  saturation > 90%  AND  storefront traffic in a burst state

• The MongoDB side is exactly the Connection Pool Saturation % gauge: how full the polled member’s connection capacity is, where the effective ceiling is current + available (the smaller of the configured maxIncomingConnections and the OS file-descriptor limit).
• The storefront side is the live traffic / session rate from the connected commerce platform, which is what tells us whether the saturation is being driven by genuine shopper demand.
• A “traffic burst” is storefront traffic running materially above its recent baseline for the window, the same definition the commerce connectors use for their own surge detection.

• The whole point is the join. Saturation alone cannot distinguish a sale-driven surge from an application connection leak. By pairing it with storefront traffic, the card answers the diagnostic question directly: did the connections rise because shoppers arrived, or for some other reason?
• The 90% line maps to imminent refusal. Connection saturation fails as a cliff: everything works until the ceiling, then new connections are refused. Pairing the 90% line with a live traffic burst flags the moment when a sale is most at risk of tipping the database into refusing connections.
• Per-member. The MongoDB side reflects the polled member, normally the primary that carries writes during a checkout-heavy burst.

​

Worked example

• At 14:05, saturation hits 92% while storefront traffic is bursting at 5.1x baseline. This is real demand: the sale brought shoppers, the shoppers drove connections, and the database is genuinely near its ceiling. The right response is capacity: raise the host ulimit -n and maxIncomingConnections to lift the ceiling immediately, and ensure the application’s driver pools are sized to ride the burst without exhausting the server.
• At 16:40, saturation is back at 93% but storefront traffic has returned to baseline (1.1x). Nobody is shopping in volume, yet connections are still pinned near the ceiling. This is the leak signature: an application instance that opened connections during the sale never returned them to the pool, or a background job is holding connections open. The fix is on the client side, not the server: find the leaking service and recycle it, then fix the connection-return behaviour.

The diagnostic in one line:
  saturation HIGH + traffic HIGH  =  capacity   (provision: lift ceiling, size pools)
  saturation HIGH + traffic LOW   =  leak       (client bug: connections not returned)

1. Saturation in isolation is ambiguous; this card removes the ambiguity. The same 90%+ reading means “buy capacity” or “fix a bug” depending entirely on whether traffic is bursting, and you cannot tell which from the database alone.
2. During a sale, the red row is a “fix it now” line. Saturation at 90%+ while traffic is still climbing means the next surge of shoppers may hit refused connections, which presents as failed checkouts. Lift the ceiling before the burst peaks.
3. The post-burst leak is the sneaky one. Saturation that stays high after traffic subsides is easy to miss because the sale is “over”, but a leaked pool will eventually exhaust the ceiling and cause an outage with no traffic to explain it. Watch the rows after the burst, not just during it.

​

Sibling cards to read alongside

​

Reconciling against the source

mongosh: db.serverStatus().connections gives current and available; compute current / (current + available) to reproduce the database half of each row. mongostat: the conn column shows the live connection count for spot checks against the table. Atlas: the Metrics tab Connections chart shows current connections against the limit; overlay it mentally with your traffic to do the same correlation by hand. Storefront side: the connected commerce platform’s own analytics (Shopify, BigCommerce or Adobe Commerce) holds the authoritative traffic / session figures the storefront column is built from.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre