Scaling out MongoDB: shards, chunks, mongos and the CAP corner

Sharding: partitioning that runs by itself

Lesson 3 met sharding as horizontal partitioning: whole rows spread over several machines. The MongoDB deck calls it "A new word: Sharding" (p. 287), "Essentially Data Partitioning", and lists what is "Different in NoSQL": "Fully automatic", "Configurable", "Transparent", "BASE principles" — "See for example MongoDB".

Read them as a division of labour: the database cuts, moves and routes by itself (automatic); a human chooses what to cut on, and how — the key and the strategy of section 4 (configurable); the application sees one database (transparent). "BASE principles" places it in the family of lesson 5; for MongoDB the deck's CAP slide is more precise (section 5).

The running example: the hospital heating system of the exam of 30 Jan 2026, plus what its ER diagram lacks — the readings each Heating System sends, one document each in a readings collection, the heater's Heater_Sys_ID stored as deviceId as on the slides. Readings grow without end, so they get their own collection (lesson 13's stop sign of unbounded growth).

Four reasons to shard

Page 288 lists them, and p. 335 comes back to all four. "Sharding is a means of partitioning data across servers to enable":

• "Scale: needed by Modern applications to support massive workloads and data volume." Each server stores and serves only its part.
• "Geo-Locality: to support geographically distributed deployments to support optimal UX for customers across vast geographies." Milan's readings on a server in Milan, Palermo's in Palermo.
• "Hardware Optimizations: on Performance vs. Cost". This month's readings on fast SSD servers, last year's on cheap disks.
• "Lower Recovery Times: to make 'Recovery Time Objectives' (RTO) feasible." The RTO is the longest outage the business accepts; three small shards restore in parallel, far faster than one big database.

Shard key, chunk, shard

"Sharding involves a shard key defined by a data modeler that describes the partition space of a data set. Data is partitioned into data chunks by the shard key, and these chunks are distributed evenly across shards that reside across many physical servers" (p. 289). And the picture to keep (p. 324): "Key space is like points on a line", "Range is a segment of that line".

Sharding cuts the shard-key line into chunks and spreads the chunks over shards: you choose the key, MongoDB cuts, moves and routes.

Who is who: mongod, mongos and the config servers

Three kinds of process run a sharded cluster: "Mongod – Database instance", "Mongos - Sharding processes" (p. 321) and the config servers (p. 326). The third program of p. 321, "Mongo", is the shell of lesson 14.

mongod, and what a shard is

mongod — the "main daemon" (p. 329) — stores documents and answers queries. A shard "is a node of the cluster" and "can be a single mongod or a replica set" (p. 327). A replica set is a group of mongod processes holding the same data: one primary, which receives every write, and secondaries, which copy those writes and can take its place — the slide draws a "Primary" box over two "Secondary" boxes.

Fig. 2 redraws the deck's picture of the cluster, the third panel of "MongoDB is fast and scalable" (p. 295). Down a column, "Replication /HA": the same data on three servers, which survive one failure. Along the row, "Horizontal Scaling": different data in each column, so another column adds capacity. A column is a replica set; the row is the set of shards.

The middle panel, "In-Memory Caching", draws memory cells feeding disks: the data in use stays in RAM, written to disk behind the scenes — "Operates at in-memory speed wherever possible" (p. 294). The first panel, data locality, is lesson 13's.

mongos, the router

Applications do not talk to the shards: they talk to mongos, "Analogous to a database router", which "Processes all requests", "Decides how many and which mongod should receive the query" and "Collates the results, and sends it back to the client" (p. 321). "How many and which" is the key phrase:

// targeted: has the shard key
db.readings.find(
  { "deviceId": 512 }
)

// broadcast: no shard key
db.readings.find(
  { "kwh": { "$gt": 5 } }
)

The first filter contains the shard key: mongos looks 512 up in the chunk map and asks the one shard holding it — a targeted query. The second does not, so mongos asks every shard and merges the answers — a broadcast (scatter-gather) query, which costs every shard work. Both names are the manual's; the slides say "routed to specific shards" (p. 326). A filter on the leading field of a composite key is targeted too. Fig. 3 follows both queries.

mongos "Acts as a router / balancer", has "No local data (persists to config database)" and "Can have 1 or many" (p. 329): "one mongos for the whole system", or "one local mongos for every client if you wanted to minimize network latency" (p. 321) — the two layouts at the bottom of p. 329. A local mongos saves a network hop; a crashed one loses nothing and reloads the map.

The config servers, keepers of the map

The map lives on the config servers, which "Stores cluster chunk ranges and locations" (p. 326): each chunk's range and its shard. mongos caches it. As the one source of truth about where data lives — p. 329 joins "Config Server", "Mongos" and "Mongod" with two-way arrows — the config servers need the protection the data has.

mongod stores, mongos routes, the config servers remember where every chunk is.

The life of a chunk: split, then migrate

"Distribution" (p. 325) tells the story in three lines: "Initially 1 chunk", "Default max chunk size: 64mb", "MongoDB automatically splits & migrates chunks when max reached". Its picture catches the middle: "Shard 1" with three chunks, "Shard 2" with one.

Two events hide in "splits & migrates". A split cuts a chunk's range in two at a shard-key value: both halves stay put, only the chunk map changes, no document moves. A migration moves one whole chunk to another shard: its documents are copied, the map updated, the old copy deleted. Migrations are the balancer's decision: "MongoDB balances cluster", "MongoDB migrates data to new nodes" (p. 326).

A split is cheap, a change of the map; a migration copies megabytes across the network, so the balancer moves as little as it can. And no chunk is on two shards: sharding divides, replication copies — which is why the failure switch hurts only a single-mongod shard.

Auto-sharding in two steps

"Auto-sharding" (p. 328) promises "Minimal effort required" in "Two steps": "Enable Sharding for a database" and "Shard collection within database". In the shell (command names from the MongoDB manual; the slides give only the steps):

// step 1: the database
sh.enableSharding("hospital")

// step 2: the collection, on
// the composite key of p. 331
sh.shardCollection(
  "hospital.readings",
  {
    "deviceId": 1,
    "timestamp": 1
  }
)

Everything after step 2 happens without you; the key is the one decision MongoDB cannot take for you.

A split only redraws the map; a migration moves a whole chunk; the balancer migrates until the shards are even.

Range, hash or tag: three ways to cut the line

"MongoDB Sharding Strategies" (p. 330) names three: "Ranged", "Hashed", "Tag-aware". All cut the key line into chunks; they differ in what places a document on the line, and in who decides which shards hold a stretch of it. (The slide's drawing labels mongos "Query Router".)

Range sharding

Range sharding "Splits shards based on sub-range of a key (or also multiple keys combined)" (p. 331) — read "splits the data". The slide gives a "Simple Shard Key: {deviceId}" and a "Composite Shard Key: {deviceId, timestamp}" (the manual says compound): pairs ordered by deviceId, then by timestamp within a device, like a phone book sorted by surname, then first name. Its two chunks (Fig. 4) split inside device 1000's readings, between two consecutive seconds.

A range key keeps neighbours together: a query for a stretch of keys — device 1000 last week — reaches one shard or a few. That is also its weakness. When the key only grows, like a timestamp, every new document lands in the last chunk, the one ending at MaxKey: one chunk, one shard, all the writes — a hot spot. The slides do not discuss it; the MongoDB manual warns about it.

Hash sharding

Hash sharding is "A subset of Range Sharding": "MongoDB apples a MD5 hash on the key when a hash shard key is used" (read "applies"), which "Ensures data is distributed randomly within the range of MD5 values" (p. 332). The slide's one formula:

"Subset" means the cutting is still by ranges — of hash values. Consecutive keys get unrelated hashes and scatter over all the chunks, so inserts spread evenly even when the key only grows. The price is the same scrambling: a range query on the key is broadcast to every shard. An equality query stays targeted, since mongos can hash the one value asked for.

Row by row: the timestamp makes time windows cheap and sends every insert to one shard; its hash spreads inserts and broadcasts every window; the composite key spreads inserts and keeps "one device, one window" on one shard.

Tag-aware sharding

The third strategy decides which shards may hold a stretch of the line: "Tag-aware sharding allows subset of shards to be tagged, and assigned to a sub-range of the shard-key" (p. 333). The example: users from 100 "regions", "Collection: Users, Shard Key: {uId, regionCode}", "Tag based on macro regions". Page 334 tags "Shard1" and "Shard2" West, "Shard3" and "Shard4" East, and assigns key ranges with the first row of the table below; the balancer keeps each range on its tagged shards. Since version 3.4 MongoDB calls tags zones; keep the slide's word at the exam.

Which sharding to use?

Page 335 closes the loop with the four reasons of p. 288 (the third column is ours).

The rule: spreading volume (scale, recovery) needs any cut; putting particular data on particular machines (regions, hardware tiers) needs tags.

Range keeps neighbours together, hash scatters them, tags pin ranges to chosen shards.

The CAP corner

The deck's last content slide, "CAP Theorem and Mongo" (p. 336), lays the MongoDB logo along the C–P edge of the triangle, next to the heading "Focus on Consistency and Partition tolerance". Its definitions: "Consistency – all replicas contain the same version of the data", "Availability – system remains operational on failing nodes", and "Partition tolarence" (read "tolerance") — "multiple entry points", "system remains operational on system split". The course notes agree: MongoDB is "built using a CP architecture".

Why CP? Because of the replica set. Only its primary accepts writes. If a partition splits a replica set, only the side that still sees a majority of the members may have a primary: it keeps it, or elects one among its secondaries. A primary left on the minority side steps down as soon as it notices, and refuses writes. Its clients get errors — availability is given up — but only the majority side's writes survive, so the data stays consistent: the CP line of lesson 5, "a timeout error or an error, otherwise". (Elections by majority are background; the slides do not describe them.)

"CP" describes the default path through the primary; each operation may choose otherwise — lesson 5's "It's at operation level!" (p. 198). In the manual's terms (background): a write can wait until a majority has it, the write concern "majority", or only for the primary; a read can go to a secondary, closer but possibly stale.

MongoDB is CP because each replica set has a single primary, and the side of a partition without a majority stops accepting writes.

Back to the busy server

The hook's cluster did everything the slides promise: one chunk, splits, migrations until every shard held the same number. But the key was the timestamp, and a timestamp only grows: every new reading falls into the chunk ending at MaxKey — on one shard. The balancer evens out what is stored, not where the next write goes: it balanced the past while the present landed in one place.

The one choice that would have spread the writes is the key. A hashed timestamp spreads them but broadcasts every time-window report; the slide's composite key {deviceId, timestamp} spreads them over the heaters and keeps "one heater, one window" on one shard — the highlighted row of the table.

And the second question: a single-mongod shard dies with its chunks — the hole in the first widget — while a replica-set shard elects a new primary and carries on. That is why every shard must be one today.