Sharded cluster architecture and query routing

conceptThe concept

Open the interactive lesson to use this diagram.

• Shards: each a replica set holding a subset of the data.
• Config servers (a replica set, CSRS): metadata, i.e. which ranges of shard key values (chunks) live on which shard, plus cluster settings. Since 8.0 a config shard can also hold application data.
• mongos: stateless routers. Applications connect to mongos, never directly to shards. Run several behind the driver's host list (or one per app host).
• A collection is sharded by a shard key. Unsharded collections live on the database's primary shard (or, since 8.0, can be moved with moveCollection).

Targeted queries include the shard key (or its prefix) so mongos sends them only to the shards that own the matching ranges. Scatter-gather (broadcast) queries go to every shard and merge results: fine for rare analytics, costly at high volume because every shard does work for every query.

whyWhy it matters

Sharding is MongoDB's way to scale writes, data size and working set beyond one replica set. It is powerful but adds components, operational work and constraints. Knowing exactly what it changes lets you decide if and when you need it.

Use caseReal-world scenario

A 12 TB order history with 30,000 writes per second does not fit a single replica set comfortably: restores take days and the working set exceeds RAM. Sharding on { customerId: "hashed" } across 6 shards spreads writes evenly; order lookups by customer are targeted to one shard; global reports become scatter-gather and run on analytics nodes.

Try itExamples

Run and edit these in the interactive lesson.

sh.status()

sh.enableSharding("shop")                                    // optional since 6.0
db.orders.createIndex({ customerId: "hashed" })
sh.shardCollection("shop.orders", { customerId: "hashed" })
sh.shardCollection("shop.events", { customerId: 1, ts: 1 })
db.orders.getShardDistribution()
db.orders.find({ customerId: 42 }).explain()                   // SINGLE_SHARD
db.orders.find({ status: "paid" }).explain()                   // SHARD_MERGE: all shards

db.orders.getShardDistribution()

internalsUnder the hood

mongos caches the routing table from the config servers and refreshes it when a shard reports a stale version (each chunk move bumps the collection's placement version). Aggregations split into a shard part (run on each shard) and a merge part (on mongos or a chosen shard). $lookup to a sharded collection works since 5.1. Unique indexes on a sharded collection must have the shard key as a prefix, because each shard can only enforce uniqueness on its own data. Transactions across shards use two-phase commit.

Avoid / preferDo this, not that

mongodb://shard-a-0:27018,shard-a-1:27018/shop

mongodb://mongos-0:27017,mongos-1:27017,mongos-2:27017/shop

mongodb://mongos-0:27017/shop

mongodb://mongos-0:27017,mongos-1:27017/shop

PitfallsCommon mistakes

• Sharding too early, adding complexity for a workload one replica set could handle.
• Sharding too late, when the cluster is already overloaded and initial balancing competes with production traffic.
• Applications connecting directly to shards.
• Running a single mongos as a single point of failure.
• Assuming unique constraints on non-shard-key fields still work across shards.

LimitsWhen not to use it

Do not shard before you need to. A well-indexed replica set on good hardware carries a lot, and archiving old data or scaling vertically is far simpler. Sharding adds config servers, routers, a shard key you will live with, and harder backups. Shard when the data set, working set or write rate has clearly outgrown one replica set.

SecuritySecurity notes

All members (config servers, shards and mongos) must use internal authentication (keyfile or x.509) and TLS. Expose only mongos to applications and block direct client access to shard ports. Users created through mongos live on the config servers; shard-local users exist only for maintenance and should be few.

ChallengeTry it yourself

const s = sh.status()
printjson({ shards: s.shards.map(x => x._id), balancerEnabled: s.balancer["Currently enabled"], mongos: s["active mongoses"] })

InterviewQuestions you should be able to answer

QuizCheck your understanding

4 questions with instant feedback in the interactive lesson; a wrong answer goes into your review deck.