If you are running a bulk update on a sharded cluster, how does the Mongos router distribute the work?

mongos instances serve as the query routers for sharded clusters, providing the only interface that applications directly interact with . Each mongos maintains a cache of cluster metadata from the Config Servers, allowing it to know exactly which shard holds which chunks of data based on shard key ranges. For write operations, mongos uses this metadata to route each operation to the appropriate shard(s). After receiving responses, mongos may need to coordinate results, though for bulk writes this primarily involves tracking success/failure status across operations .

The ordered parameter significantly affects how mongos distributes bulk write work. With ordered operations (ordered: true), mongos executes operations serially in the sequence provided. Each operation must complete before the next begins, and if an error occurs, processing stops . This sequential approach is generally slower for sharded clusters because operations cannot be parallelized . With unordered operations (ordered: false), mongos can execute operations in parallel and may even reorder them to maximize performance . The MongoDB documentation specifically notes that unordered operations are typically faster for sharded collections because mongos attempts to send writes to multiple shards simultaneously .

mongos determines target shards by examining the update filter and comparing it to cached chunk metadata from the Config Servers . For sharded collections, data is divided into chunks, each covering a range of shard key values and assigned to a specific shard. When an update includes a shard key value, mongos performs a binary search through its chunk metadata to identify which shard owns the chunk containing that key range. This process is extremely fast and memory-efficient. For updates without shard keys, mongos must default to broadcasting .

A common misconception is that all operations in a bulk array must go to the same shard. In reality, each operation is evaluated independently. For example, if your bulk update contains 10,000 operations with different shard key values spanning multiple shards, mongos will route each operation to its appropriate shard . With unordered execution, these operations can be dispatched in parallel across shards, utilizing the full write capacity of the cluster. This is why unordered bulk writes are recommended for maximizing throughput in sharded environments .