Your application is growing — hey, good for you! You’re gaining more active users, adding new features, and generating more data every day. There’s just one problem: Your database is slowing down your application. It’s time to scale — either by growing up or growing out.
Growing up means scaling vertically — like adding more stories to a building. It works for a while, but you can only build so high before hitting physical and financial limits.
Growing out means scaling horizontally — like developing the lots around you with new buildings and extending your city’s infrastructure to support them.
In MongoDB, horizontal scaling is known as sharding. Sharding divides a large database into smaller, more manageable pieces, called shards. Each shard contains, stores, and performs requests for just a subset of your data, dividing your total workload to increase throughput, storage capacity, and resiliency.
But how does MongoDB know how to divide your workload? Well, you need a shard key. A shard key determines which shard each document belongs to based on the indexed field you choose to organize by.
A good shard key has high cardinality and even frequency. High cardinality means many possible values, allowing data to spread across more shards. Even frequency means those values appear in a balanced way — if one value holds 95% of records, you’ll create a hotspot and overload a single shard. Keep both in mind when choosing your shard key.
But don’t sweat it too much — MongoDB also lets you reshard to adopt a better strategy if your priorities or needs change.
Once you’ve defined a good shard key, MongoDB needs a way to use it to route each request to the right place.
The mongos is that router. It figures out where your data lives, routes reads and writes to the right shards, and then formats results into a clear response.
To talk to those routers, your application needs MongoDB drivers. These drivers are “cluster-aware”—they understand the topology, so they know exactly which mongos to connect to.
For mongos to know where everything is, it relies on one more critical piece of the system.
That’s the config server replica set — the source of truth for your metadata. It stores everything the cluster needs to know: which collections are sharded, how chunks are split and distributed, and the routing information that mongos uses to do its job.
Put it all together, and you get a sharded cluster that scales with you like a city that expands building by building. It distributes data, routes queries intelligently, and adapts as your application grows. It’s a system designed to handle more and move faster, and it all happens on MongoDB. Learn more at the link in the description.
