MongoDB Architecture Explained: Documents, WiredTiger, Replica Sets, and Sharded Clusters

MongoDB Architecture Explained: Documents, WiredTiger, Replica Sets, and Sharded Clusters

MongoDB's architecture has several layers that solve different problems: BSON documents and collections define the data model, WiredTiger handles local storage and durability, replica sets provide redundancy and failover, and sharded clusters distribute collections across multiple replica sets.

Understanding those layers explains why MongoDB behaves the way it does under writes, failures, memory pressure, secondary reads, and horizontal scaling.

The core server: mongod

A normal MongoDB database server runs as a mongod process.

At a high level it handles:

client request
   |
query / command layer
   |
collection + index operations
   |
WiredTiger storage engine
   |
files + journal on storage

A standalone mongod is useful for local development, but production systems normally use replica sets so a single node failure does not make the database unavailable.

Documents are stored in collections

MongoDB stores BSON documents inside collections.

A document can contain nested objects and arrays:

{
  "_id": "o_900",
  "customer_id": "u_42",
  "status": "paid",
  "shipping": {
    "city": "Agra",
    "country": "IN"
  },
  "items": [
    { "sku": "p1", "qty": 2 }
  ]
}

The flexible document model is useful when related data is naturally read and updated together.

But embedding everything into one document can create unbounded arrays, large-document rewrites, and awkward concurrency. Data modeling should choose deliberately between embedding and referencing.

Indexes sit beside the collection data

Without a useful index, MongoDB may need to examine many documents to answer a query.

Indexes can support:

• equality lookups
• compound predicates
• sorting
• unique constraints
• geospatial queries
• text/search capabilities depending on deployment

A compound index should follow real query shapes and field order.

Architecture-level scaling cannot compensate for an application whose hottest queries repeatedly scan large collections.

WiredTiger is the default storage engine

Current MongoDB Community, Enterprise, and Atlas deployments use WiredTiger as the standard storage engine.

WiredTiger is responsible for local concerns such as:

• data/index pages
• caching
• compression
• checkpoints
• concurrency at the storage-engine layer
• journal-based crash recovery

MongoDB uses both the WiredTiger internal cache and the operating system's filesystem cache, so host memory planning should leave room for more than only the WiredTiger cache itself.

Journaling protects writes between checkpoints

WiredTiger uses checkpoints plus a write-ahead journal.

Conceptually:

write
  |
WiredTiger memory state
  |
  +--> journal
  |
checkpoint -> durable data files

If MongoDB exits unexpectedly after the last checkpoint, journal records can be replayed during recovery.

MongoDB documentation notes that journaling is always enabled in modern MongoDB releases using this architecture.

The durability seen by a client also depends on the operation's write concern—not merely on the existence of journal files.

Compression is part of the storage architecture

WiredTiger supports compression for collections and indexes, and the journal is compressed as well.

Compression reduces storage and I/O at the cost of CPU work.

The effective trade-off depends on:

• data shape
• storage performance
• CPU availability
• working-set size

Do not estimate MongoDB storage only from uncompressed BSON payload size.

A replica set adds a distributed durability layer

A MongoDB replica set contains a primary and secondary members.

              writes
                |
                v
             primary
            /       \
       secondary   secondary

The primary records operations in the oplog. Secondaries asynchronously replicate and apply those operations.

Replica sets provide:

• redundant copies
• automatic primary election
• failover
• maintenance/backup options
• optional secondary reads

Replication does not remove the need for backups: a valid accidental delete can be replicated successfully to every member.

The oplog is the replication change history

The oplog is a capped collection containing an ordered history of changes used by replica-set members.

A secondary must stay close enough to the primary that it can continue fetching required oplog entries.

If a secondary falls so far behind that the required history has rolled out of the oplog, it may need a new initial synchronization instead of ordinary catch-up.

Therefore monitor:

• replication lag
• oplog window
• write bursts
• secondary storage/CPU health

The oplog window should comfortably exceed realistic maintenance/outage scenarios.

Elections change which node is primary

If the primary becomes unavailable, eligible members hold an election and one can become the new primary when the replica set can form the required majority.

During election/failover:

• writes can temporarily fail or pause
• clients/drivers must discover the new primary
• in-flight operations can have ambiguous outcomes

Applications should use official topology-aware drivers and retry only operations whose retry semantics are safe.

A network partition can leave a healthy server unable to remain primary if it cannot communicate with the required voting majority. That protects against two independent writable primaries creating divergent history.

Write concern defines acknowledgement

MongoDB write concern controls what acknowledgement the client requests.

Conceptually:

w: 1        -> primary acknowledgement
w: majority -> acknowledgement according to majority write-concern semantics
j: true     -> include journal durability requirement where applicable

The exact guarantees and latency depend on topology and configuration.

Stronger acknowledgement generally adds coordination but narrows some failure windows. Choose from business durability requirements rather than benchmark speed alone.

Read preference decides where reads go

By default, reads target the primary.

MongoDB supports other read-preference modes for workloads that intentionally read from secondaries or low-latency eligible members.

Secondaries replicate asynchronously, so secondary reads can be stale.

Read preference therefore affects:

• consistency/freshness
• latency
• primary load
• failure behavior

It should not be treated as a free read-scaling switch for every endpoint.

Read concern controls what version is acceptable

Read concern provides another consistency/isolation dimension.

Different levels can control whether a query may observe data that has not reached stronger replication/durability points or whether it requires a more stable snapshot.

The correct combination of read preference, read concern, and write concern depends on the workflow.

A payment/account mutation and an analytics dashboard can reasonably use different guarantees.

Transactions build on replica-set/sharded infrastructure

MongoDB supports multi-document transactions on replica sets and sharded clusters.

That is useful when one business invariant cannot be safely represented as a single-document atomic update.

But transactions are not free. They hold snapshots/resources and, in a sharded cluster, can require coordination across shards.

Prefer good document boundaries that keep frequently atomic state together, then use transactions when the invariant genuinely spans documents.

Sharded clusters add a routing layer

When one replica set is no longer enough for storage/write distribution, MongoDB can shard collections.

A sharded cluster contains:

applications
    |
  mongos
    |
    +--> shard A replica set
    +--> shard B replica set
    +--> shard C replica set
    |
config server replica set

Shards

Each shard owns a subset of sharded collection data and must itself be a replica set in modern production sharded clusters.

mongos

mongos is the query router. Applications connect through routers; mongos uses sharding metadata to target operations to the appropriate shards.

Config servers

Config servers store sharded-cluster metadata such as shard/range ownership. They run as a replica set so that metadata has its own availability/consistency protection.

MongoDB 8.x can also use a config shard, where a config-server role shares a shard replica set, for supported deployments. Dedicated config servers remain useful/required for particular features and isolation requirements.

The shard key becomes part of the architecture

MongoDB uses a shard key to determine distribution.

A well-chosen key gives mongos enough information to target queries and distributes data/write traffic well.

A poor key creates:

• hotspots
• scatter-gather queries
• skewed shard sizes
• expensive resharding later

This topic is covered deeply in the MongoDB scaling article because shard-key design is primarily a scaling/data-distribution decision.

Config metadata is critical infrastructure

Config servers track information such as which ranges/chunks live on which shards.

Routers cache this metadata and refresh it when topology/distribution changes.

This means a sharded cluster has both:

• a data plane: application documents on shards
• a control plane: metadata used to route and manage that data

Administrative operations on config servers should be treated carefully because metadata availability affects cluster management and, in severe failures, cluster operation.

Change Streams expose the replication/change layer safely

MongoDB Change Streams let applications subscribe to database changes without manually tailing the oplog.

Typical uses include:

• event-driven integrations
• cache invalidation
• search-index updates
• audit/notification pipelines

Consumers should still be idempotent and checkpoint/resume correctly because distributed consumers can restart and replay events.

Do not treat a Change Stream as magical exactly-once business delivery without designing consumer semantics.

Memory pressure shows up in the storage engine

A healthy MongoDB deployment wants its active working set and useful index pages to benefit from memory/cache.

When the workload greatly exceeds memory, the system can become increasingly storage-I/O-bound.

Watch:

• WiredTiger cache eviction/activity
• page faults/storage latency
• index working set
• query latency
• cache pressure

Scaling RAM can be very effective when the real problem is a working set that barely misses cache—not a reason to shard immediately.

Large documents and arrays change write behavior

A MongoDB document is an atomic update boundary for many normal operations, which is useful.

But huge documents or arrays can create:

• larger network payloads
• more memory pressure
• more update work
• document-size limits
• contention when many writers modify the same document

Bound embedded collections and move independently growing data into separate documents/collections when appropriate.

Architecture failure modes to understand

Primary unavailable

Writes pause until a new eligible primary is elected.

Secondary lagging

Secondary reads may become stale, and the member can risk falling outside the oplog window.

One shard unavailable

In a sharded cluster, data on that shard becomes unavailable while targeted operations on healthy shards can potentially continue.

Config metadata unavailable

Cluster management/routing metadata operations can become constrained; severe config-server failure can make the cluster inoperable.

Storage full

Journals, checkpoints, indexes, and data all need disk headroom. Disk exhaustion is an availability failure, not simply a capacity warning.

What to monitor

For replica sets:

• primary/secondary roles
• election events
• replication lag
• oplog window
• write/read latency
• WiredTiger cache
• journal/checkpoint behavior
• disk space and storage latency

For sharded clusters, add:

• per-shard data/traffic
• balancer/range migration
• scatter-gather frequency
• config-server health
• router errors/stale metadata refreshes
• shard hotspots

A practical mental model

Think about MongoDB in layers:

BSON document model
        |
collections + indexes
        |
WiredTiger storage + journal/checkpoints
        |
replica set for redundancy/failover
        |
sharding + mongos + config metadata for horizontal scale

Each new layer solves a real problem and introduces its own operational semantics.

Start with the simplest layer set that satisfies the workload. A replica set is not a sharded cluster, and a sharded cluster does not rescue weak document/index design.

Official references

• MongoDB WiredTiger Storage Engine
• MongoDB Journaling
• MongoDB Replication
• MongoDB Sharding
• MongoDB Config Servers