How Observe.AI Used MongoDB Resharding to Scale Its AI Platform

Launched in 2017, Observe.AI was originally known for its expertise in conversation intelligence and contact center analytics. In recent years, however, the company has grown into a comprehensive agentic AI platform, and now has three core offerings:

• AI agents for customers that resolve customer requests across voice and chat.

• AI agents for frontline teams. These include Observe.AI’s recently launched Companion Agent, which provides human team members real-time guidance and automates work before, during, and after customer interactions.

• AI agents for operations that evaluate interactions, generate coaching, uncover operational insights, and drive continuous improvement across contact centers.

Observe.AI uses MongoDB Atlas as the foundational data layer for its AI platform and relies on it to store raw customer conversations, AI-generated enrichments, model configurations, and agent metadata.

MongoDB's flexible document model enables rapid iteration as AI models evolve, while its scalability—supporting over 100 clusters and 50+ TB of data—has made it the trusted system of record powering our platform's intelligence layer.

Recently, the team wanted to continue scaling with MongoDB in a way that preserved application availability, reduced operational risk, and created a predictable runway for continued data growth.

The team partnered with MongoDB Consulting’s professional services to scale a production-critical MongoDB Atlas deployment to support Observe.AI’s conversation intelligence platform. The project was a joint engineering effort between Observe.AI and MongoDB that used MongoDB resharding as a practical, online mechanism for redistributing large collections across a broader shard footprint.

Expanding a constrained shard footprint

At the time of the project, the cluster had the following characteristics:

• A sharded MongoDB Atlas deployment with two data shards plus config servers.

• Approximately 13 TB of compressed data per data shard, representing roughly 50 TB of uncompressed data overall.

• Each shard runs on the M140 tier with a disk limit of approximately 14 TB, leaving limited available headroom.

• A sustained ingest rate of roughly 50 GB per day, making proactive capacity expansion important for safe long-term operations.

• Several multi-TB collections with significant index footprint and production traffic. This setup had worked at an early stage in the company's cycle, but was no longer fit for purpose and could lead to performance issues or service degradation that would directly impact customers.

The engineering objective of the MongoDB–Observe.AI effort was clear: to expand a constrained shard footprint to a healthier horizontal layout, while also keeping the application online and minimizing disruption to production workloads.

Beyond balancer: a faster redistribution for large-scale data movements

After adding new shard capacity, the team evaluated the default balancer-driven redistribution path. They determined that the balancer was the right tool for ongoing incremental balancing, but the volume of data to be redistributed was large enough that relying on chunk migrations alone would have extended the migration window and kept the original shards under elevated pressure for longer than desired.

The team also tackled a number of other constraints. First, the new shard capacity could receive data, but the pace of redistribution was bounded by balancer and range-deletion throughput; range deletion also created additional background load on shards that were already carrying production traffic. Secondly, existing shards periodically experienced high WiredTiger cache pressure, making it important to avoid prolonged competition between application traffic, balancing, and cleanup activity. Finally, the team wanted a controlled, predictable migration path rather than an extended background redistribution process.

They concluded that the balancer should continue to handle incremental corrections, but a faster and more explicit redistribution mechanism was needed for the initial large-scale data movement.

The four-step resharding plan

Instead of relying solely on balancer migrations, the MongoDB–Observe.AI team designed a controlled resharding plan:

1. Scale out the cluster

• Increase capacity by adding multiple new shards (not just one) so that, after redistribution, each shard would hold a manageable share of the ~50 TB dataset.

2. Prepare the cluster for resharding

• Ensure no ongoing migrations or resharding jobs.

• Pin the config servers to remain embedded/dedicated as appropriate for this topology.

• Disable range deletions and disallow chunk migrations for critical collections so that resharding traffic does not compete with the balancer and range deleter for IOPS.

3. Run resharding on the largest collections

• For each large collection (collection6, collection7, collection8, etc.), run reshardCollection to redistribute data across the new shard set, keeping the same shard key but changing the ownership distribution.

• Execute resharding sequentially per collection to avoid overloading donors, recipients, or the config server.

Table 1. Resharding performance metrics.

4. Clean up and return to normal operations

• Once data has been redistributed:
• Remove old empty shards from the cluster.
• Remove temporary zone configurations that were only needed during the migration.
• Re‑enable balancing and range deletions for the now‑healthy collections.

Resharding driving greater optimization, performance, and reliability

The joint effort gave Observe.AI a safer and more scalable data foundation for continued platform growth.

Thanks to resharding, the cluster moved from a limited disk runway to a healthier multi-month capacity position, while large multi-TB collections were redistributed across the expanded shard footprint using online resharding rather than relying only on extended balancer-driven chunk migration.

Production reads and writes continued during the clone and catch-up phases, with only the final commit phase requiring a brief write-blocking critical section. The team reduced sustained pressure on the original shards and created more room for future ingest growth, maintenance, and operational flexibility.

Finally, after the migration, the MongoDB balancer returned to its normal role of incremental rebalancing, while the heavy data movement was handled through the more appropriate resharding workflow.

The project highlighted how sharding and resharding can be used proactively as part of ongoing capacity management, helping optimize storage utilization, manage growing data volumes, and maintain platform performance and reliability as workloads scale.

Combining horizontal scale-out and resharding: A winning combo

The key idea behind MongoDB’s resharding capability is simple—sharding should not be the last‑resort, once‑in‑a‑lifetime operation you dread. It should be a practical, fast tool you can use whenever your workload outgrows its current shape.

If you treat sharding as “too expensive” and delay it until your primary is holding tens of TBs, you pay that cost back many times in:

• Oversized single replica sets,

• Operational risk,

• And slow, painful balancing when you finally add shards.

By combining horizontal scale-out with resharding, which has been available since MongoDB 8.0 launched in 2024, you can start small, grow organically, and still have a predictable, efficient path to redistribute data when your cluster—and your business—takes off.

Observe.AI’s  platform processes billions of customer interactions each year, so the infrastructure has to scale as seamlessly as the business. Working alongside the MongoDB team enabled Observe.AI to redistribute more than 50 TB of production data with virtually no disruption to customers. MongoDB 8.0 resharding provided  the operational confidence to expand capacity proactively instead of reacting to infrastructure limits, allowing Observe.AI’s engineering teams to stay focused on delivering innovation for customers.