Using MongoDB Atlas Workload Management to Protect Busy Clusters

A MongoDB cluster can perform well under normal traffic and still struggle when application demand increases suddenly.

A new product launch, a reporting job, a background data-processing task, or an inefficient query can create more database activity than the cluster can handle. When this happens, query latency increases, connections become harder to establish, and application requests may begin failing.

Increasing the cluster tier can provide additional resources, but scaling is not always immediate. It also does not solve every workload problem. A single expensive query or a sudden connection spike can affect other operations before additional capacity becomes available.

MongoDB Atlas provides workload management capabilities to help protect clusters under these conditions. These include request queueing, execution prioritization, connection rate limiting, memory management, and optional load shedding.

MongoDB calls this capability Intelligent Workload Management (IWM).

Understanding how these protections work helps developers design applications that remain responsive during periods of high database activity.

What Is Intelligent Workload Management?

Intelligent Workload Management is an Atlas-managed availability capability that helps maintain cluster responsiveness when incoming operations exceed available resources.

Without workload protection, a cluster receiving more operations than it can process may accumulate a large amount of pending work. As queues grow, response times can increase, and resource contention can affect otherwise healthy operations.

IWM addresses this problem through several mechanisms.

Its protections include:

Ingress queueing to control how quickly operations enter the database.
Execution control prioritization to help shorter operations progress during overload.
Cache eviction and memory tuning to manage memory pressure.
Connection rate limiting to control sudden increases in new connections.
Optional load shedding to reject operations when sustained overload cannot be handled by queueing alone.

IWM is not a replacement for query optimization, capacity planning, or application-level traffic management. It is an additional layer of protection.

Which Clusters Support IWM?

IWM is active on Dedicated Atlas clusters running MongoDB 9.0 or later.

It is not available on Free or Flex clusters.

The protections available depend on the cluster tier, topology, MongoDB version, and configuration.

For example, the documented protection availability on MongoDB 9.0 and later is:

Protection	M10 and M20	M30+ replica set	M30+ sharded cluster
Ingress queueing	No	Yes	No
Execution prioritization	No	Yes	No
Cache eviction and memory tuning	Yes	Yes	Yes
Connection rate limiting	Yes	Yes	Yes
Write blocking	Yes	Yes	Yes
Load shedding	No	Yes, when enabled	No

Some protections are also available on earlier MongoDB versions. For example, connection rate limiting applies to certain M10 and M20 versions, while memory and write protections have separate version requirements.

Always check the current Atlas documentation for the exact combination of tier, topology, and MongoDB version used by your cluster.

How Atlas Controls Incoming Database Operations

One of the main challenges during a traffic spike is controlling how quickly incoming operations reach the database.

Suppose an application normally sends 500 database operations per second. A sudden traffic increase raises that number to 5,000 operations per second.

If the cluster cannot execute operations at the same rate, pending work begins to accumulate.

IWM uses an ingress request rate limiter on each applicable mongod process.

The rate limiter controls how quickly operations are admitted for execution. Operations that arrive faster than the admission rate are placed in an ingress queue.

This helps prevent every incoming request from competing for database resources immediately.

Ingress Queueing

Ingress queueing provides a controlled waiting area for operations that cannot be admitted immediately.

Consider the following example:

An application sends database operations to a cluster.
The cluster reaches its current processing capacity.
The rate limiter slows the admission of additional operations.
Excess operations wait in the ingress queue.
Operations enter execution as capacity becomes available.

This can help absorb short traffic spikes without immediately rejecting every additional operation.

However, queueing is not free. Waiting operations increase response latency.

If the incoming workload remains higher than the cluster's processing capacity, the queue can continue growing when load shedding is disabled.

Developers should monitor queue depth and queue time rather than assuming that a successfully queued operation will complete within the application's response-time requirements.

Understanding Execution Control Prioritization

Not every database operation has the same execution requirements.

Consider an application that handles online purchases and also generates daily sales reports.

The application may execute:

Short product lookup queries.
Order creation transactions.
Payment status updates.
Large reporting aggregations.
Background index or maintenance operations.

During normal operation, these workloads may share cluster resources without noticeable problems.

During overload, long-running operations can consume resources for extended periods.

Execution control prioritization helps short-running reads and writes continue making progress by deprioritizing background tasks and long-running operations under resource pressure.

This does not mean Atlas understands the business importance of every query.

A long-running operation may be important to the application, but the database cannot automatically know that it is more important than a short customer-facing request.

Developers should therefore separate critical application operations from expensive background work where possible.

Reduce the Impact of Expensive Queries

Consider a reporting query that reads a large collection and calculates sales totals.

db.orders.aggregate([
  {
    $match: {
      status: "completed"
    }
  },
  {
    $group: {
      _id: "$customerId",
      totalSales: {
        $sum: "$amount"
      }
    }
  }
]);

If the collection contains millions of documents, this aggregation may consume substantial resources.

Start by examining the query execution plan:

db.orders
  .explain("executionStats")
  .aggregate([
    {
      $match: {
        status: "completed"
      }
    },
    {
      $group: {
        _id: "$customerId",
        totalSales: {
          $sum: "$amount"
        }
      }
    }
  ]);

Review the number of documents examined, execution time, and whether the query uses an appropriate index.

An index on a frequently filtered field may reduce the amount of data that needs to be examined.

For example:

db.orders.createIndex({
  status: 1
});

The right index depends on the application's query patterns and data distribution. Adding indexes without reviewing write overhead and storage usage can create other performance problems.

Understanding Load Shedding

Queueing can help manage temporary overload, but it cannot solve a workload that continuously exceeds the cluster's capacity.

Load shedding provides another level of protection.

When enabled, Atlas bounds the size of the ingress queue on each applicable mongod process.

If an operation arrives while the queue is full, Atlas rejects it with an overload error.

This prevents pending operations from accumulating without a defined limit during sustained overload.

When Should You Enable Load Shedding?

Load shedding is available for M30 and higher replica set clusters running MongoDB 9.0 or later.

It is not available for M10 or M20 clusters, or for M30+ sharded clusters under the documented IWM configuration.

Atlas provides an Intelligent Workload Management setting in the cluster's additional settings.

Depending on the supported configuration, you can manage Load Shedding through the Atlas UI or Atlas Administration API.

The setting can use Atlas Managed behavior or an explicitly configured state.

Do not enable it without reviewing how the application handles overload errors.

When load shedding rejects an operation, the application may receive an error instead of a successful database response.

A client that does not handle this condition correctly may expose unnecessary failures to users.

Handle Overload Errors in the Application

An application should distinguish between transient overload and permanent database errors.

Blindly retrying every failed operation can make an overloaded cluster even busier.

Use bounded retries with exponential backoff and jitter where retrying is safe.

For example, a Node.js application can use a retry wrapper for an operation that is safe to repeat:

async function retryWithBackoff(
  operation,
  maxAttempts = 3
) {
  let lastError;

  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    try {
      return await operation();
    } catch (error) {
      lastError = error;

      if (attempt === maxAttempts - 1) {
        break;
      }

      const baseDelay = 200 * Math.pow(2, attempt);
      const jitter = Math.random() * 100;

      await new Promise(resolve =>
        setTimeout(resolve, baseDelay + jitter)
      );
    }
  }

  throw lastError;
}

Use this wrapper only after identifying which errors are appropriate to retry.

In production, inspect the error code and error labels exposed by the MongoDB driver and follow the retry guidance for the relevant operation.

Also consider the following:

Do not retry validation errors.
Do not retry authentication failures.
Avoid unlimited retry loops.
Apply an overall request deadline.
Use idempotency controls for operations that modify data.
Record retry attempts for monitoring.

For transactions and writes, retry behavior needs particular care. A request that fails after the server has performed a write should not be repeated blindly.

Control Connection Spikes

A database can experience overload even when query volume is not unusually high.

One common cause is a connection storm.

A connection storm occurs when many application clients attempt to establish new database connections within a short period.

This can happen when:

Multiple application instances restart together.
An autoscaling event creates many new containers.
Connection pools are configured incorrectly.
A network interruption causes many clients to reconnect.
Applications create a new database client for every request.

Atlas uses connection rate limiting to control how quickly new connections are accepted by each node.

When the connection rate limit is reached, Atlas queues new connection attempts. If the overload continues, some connections may be dropped.

This helps preserve existing connections and protects the cluster from excessive connection creation.

Use Connection Pooling Correctly

Applications should reuse MongoDB clients rather than creating a new client for every request.

For example, in a Node.js application:

const { MongoClient } = require("mongodb");

const client = new MongoClient(
  process.env.MONGODB_URI,
  {
    maxPoolSize: 50,
    minPoolSize: 5,
    maxIdleTimeMS: 60000
  }
);

async function connectDatabase() {
  await client.connect();

  return client.db("store");
}

module.exports = {
  connectDatabase
};

Create the client once during application initialization and reuse it across application requests.

The pool settings above are examples, not universal recommendations.

Choose pool sizes based on application concurrency, the number of application instances, and the cluster's connection limits.

Remember that a pool configured for 50 connections across 20 application instances can potentially create a much larger total connection demand than expected.

Separate Reporting Workloads From Application Traffic

One of the most effective ways to protect an operational database is to avoid making every workload compete for the same resources.

For example, an e-commerce application may execute customer-facing operations and analytical reports against the same cluster.

Large reporting queries can affect the performance of normal application requests.

MongoDB Atlas supports analytics nodes for workload isolation on eligible Dedicated clusters.

Analytics nodes can handle analytical operations without competing directly with the operational workload in the same way as queries running on the primary and standard secondary nodes.

To use them, configure suitable read preference tags and direct eligible reporting queries to the analytics nodes.

A reporting connection can use a tag-based read preference:

mongodb+srv://username:[email protected]/store
?readPreference=secondary
&readPreferenceTags=nodeType:ANALYTICS

The exact tag configuration must match the tags exposed by the Atlas deployment.

Do not route all application reads to analytics nodes. Customer-facing reads may require the consistency behavior provided by the normal replica set members.

Analytics nodes are available for eligible Dedicated deployments, generally M10 and higher. Confirm the supported topology and configuration before relying on them.

Monitor Workload Management Metrics

Workload management is useful only when the team can identify when it is active and understand its impact.

Atlas provides metrics related to operation rate limiting and connection rate limiting.

Important operation rate limiting metrics include:

Metric	What it tells you
Offered Operations	Average operations per second presented to the rate limiter
Successful Operations	Average operations per second admitted for execution
Rejected Operations	Operations per second rejected because the system is overloaded
Operation Queue Time	Average time operations spend waiting in the queue
Queued Operations	Rate at which operations are added to the queue
Current Queue Depth	Number of operations currently waiting

These metrics help distinguish between a traffic increase and a capacity problem.

For example, a high offered operation rate combined with a growing queue depth may indicate that the cluster is receiving more work than it can admit for execution.

A sustained rejection rate indicates that load shedding is rejecting operations or that the applicable rate limiter is rejecting work under overload.

Configure Alerts

Use Atlas alert conditions to monitor workload behavior.

Useful alerts include:

Intelligent Workload Management events.
Operation rate limiting activity.
Connection rate limiting activity.
High CPU utilization.
High memory utilization.
Elevated query execution time.
Increased application error rates.

Avoid alerting on every brief metric fluctuation.

Define thresholds and evaluation periods that match the application's service-level objectives.

For example, a short queue increase during a deployment may not require immediate intervention. A queue that continues growing alongside increased request latency may require investigation.

Common Mistakes When Using Atlas Workload Management

Mistake	Why it causes problems	Better approach
Treating queueing as unlimited capacity	Queued operations still consume time and can increase latency	Monitor queue depth and queue time
Enabling load shedding without application changes	Overload errors may reach users	Implement bounded retries and backpressure
Retrying every database error	Retries can increase cluster pressure	Retry only suitable transient failures
Creating a MongoDB client for every request	Creates unnecessary connection churn	Reuse clients and connection pools
Running large reports on operational nodes	Analytical workloads can affect application latency	Consider analytics nodes
Increasing the cluster tier without query analysis	Inefficient queries remain inefficient	Inspect execution plans first
Ignoring application deadlines	Operations may wait longer than the user request allows	Use bounded timeouts and cancellation
Assuming every cluster has identical protections	Availability differs by tier, topology, and version	Verify the supported configuration

Advantages and Disadvantages of Intelligent Workload Management

Advantages

Helps protect clusters during periods of high database activity.
Queueing can absorb short traffic spikes.
Execution prioritization helps short-running operations progress during overload.
Connection rate limiting protects against sudden connection storms.
Memory management helps control resource pressure.
Optional load shedding prevents unbounded queue growth on supported configurations.
Atlas metrics provide visibility into queued and rejected operations.

Disadvantages

Some protections are available only on specific cluster tiers and MongoDB versions.
Queueing can increase application latency.
Load shedding can produce errors that applications must handle.
Long-running operations may take longer during overload.
Workload management does not replace query optimization or capacity planning.
Analytics nodes and other isolation features may add infrastructure costs.

Summary

MongoDB Atlas Intelligent Workload Management helps protect eligible clusters when incoming database operations exceed available resources.

It uses mechanisms such as ingress queueing, execution prioritization, connection rate limiting, and memory management to control resource pressure. Optional load shedding can reject additional operations when sustained overload fills the configured queue on supported clusters.

For application developers, the important part is understanding how these protections affect database requests.

Use connection pooling, optimize expensive queries, separate analytical workloads where appropriate, and implement bounded retry behavior for transient overload errors.

Finally, monitor queue depth, operation latency, rejected operations, and connection activity.

Workload management can help a busy MongoDB cluster remain more predictable, but reliable performance still depends on application design, query efficiency, and choosing infrastructure that matches the workload.