MongoDB Architecture

Introduction

A MongoDB deployment is a hierarchy: cluster → replica set / shard → mongod process → database → collection → document. Understanding this hierarchy is the difference between a system that scales and one that falls over at the first traffic spike.

Understanding the topic

Major architectural components:

• mongod — the database server process.
• mongos — query router for sharded clusters.
• Replica Set — 1 primary + N secondaries for HA.
• Shard — a slice of data; collection is partitioned across shards by shard key.
• Config Servers — store cluster metadata.
• WiredTiger — the default storage engine (compression, document-level locking).

Syntax reference

Client App
   │
   ▼
mongos (router)        ◄── sharded only
   │
   ├──► Shard 1 (Replica Set: P + S + S)
   ├──► Shard 2 (Replica Set: P + S + S)
   └──► Shard 3 (Replica Set: P + S + S)

Config Servers (3-node RS)

Real-world use

An Atlas M40 cluster you spin up today is exactly this architecture: a 3-node replica set with WiredTiger storage. As you scale, you add shards and a mongos tier.

Best practices

• Always deploy at least 3 data-bearing nodes per replica set.
• Place replicas in different availability zones for true HA.
• Shard only when a single replica set can no longer hold or serve the data.