In a standalone deployment (generally for development) or a replica set deployment (minimum recommended for production environments) each
mongod process stores the same data.
If your use case merits a larger or more distributed deployment, sharded clusters allow you to define a per-collection shard key index to distribute data. Sharded clusters have additional infrastructure components including config servers which keep track of the sharded cluster metadata and
mongos processes which route queries to the correct member(s) of the sharded cluster based on the query and collection’s sharding metadata.
A database in a sharded cluster can have both unsharded and sharded collections. Unsharded collections live on primary shard for each database; data in sharded collections is partitioned across available shards based on a chosen shard key for the collection. For more information, please review
mongos Routing and Results Process in the MongoDB documentation.
From an application/driver point of view, you generally do not have to keep track of the cluster topology. The driver API includes discovery of changes in configuration and availability for replica sets and sharded clusters. However, you can specify read preferences if you want to route queries to specific members of a replica set and set up up zones for sharded clusters for more control over read and write distribution of sharded data.
If you would like a more detailed introduction to MongoDB deployments and configuration, there are free online courses for DBAs at MongoDB University including M103: Basic Cluster Administration.