Sharding is MongoDB's strategy for horizontal scaling, enabling databases to handle data sets and throughput levels that exceed the capacity of any single server. In a sharded deployment, data is distributed across multiple machines called shards, with each shard holding only a subset of the total data. The basis for this distribution is a shard key, an indexed field or compound of fields that MongoDB uses to determine where each document belongs.
A sharded cluster consists of three main components. Shards store the actual data, and each shard is itself a replica set, providing both scalability and redundancy. Config servers store metadata and configuration information for the entire cluster, including the mapping of shard key ranges to shards. Mongos instances act as query routers, receiving client operations and directing them to the appropriate shards based on the shard key. Clients typically connect to one or more mongos processes rather than directly to shards, which insulates applications from the underlying distribution of data.
Choosing a good shard key is one of the most consequential decisions in sharded cluster design. An effective shard key should have high cardinality, low frequency so that no single value dominates, and should distribute writes evenly across shards. A poor shard key leads to hot spots, where one shard receives disproportionately more traffic and becomes a bottleneck. Once chosen, the shard key is difficult to change, so careful planning and testing are essential before deployment.