MongoDB Overview and Architecture
Processes and topology
A mongod process serves databases, each holding collections of BSON documents. A replica set has exactly one primary that accepts writes, one or more secondaries that continuously apply the primary's oplog, and optionally arbiters that vote in elections but store no data and can never become primary. Sharded clusters add mongos routers that route queries and config servers that store cluster metadata; you only meet these in sharded deployments.
Storage engine
WiredTiger provides document-level concurrency control, a write-ahead journal for crash recovery, and checkpoints (default every 60 seconds). Its cache is roughly half of (RAM minus 1 GB). The 16 MB document limit and 100-level nesting limit are server-level rules independent of the engine.
Consistency knobs
Write concern (w:1, w:majority) controls how many members must acknowledge a write; read preference (primary, secondary, nearest) controls where reads are routed; read concern (local, majority, linearizable, snapshot) controls how durable the returned data is. Retryable writes let the driver safely resend a single-statement write after a network blip.
Traps
Questions love the arbiter: it adds voting members without adding data redundancy, so a 2-node-plus-arbiter set has no fault tolerance for data. Also remember that a write acknowledged with w:1 can be rolled back if the primary dies before replicating, whereas w:majority acknowledgements survive failover. Secondary reads are eventually consistent unless you use causal consistency sessions.
Rule of thumb
If a write must never be lost on failover, use w:"majority"; if it must also be read back consistently from the primary, pair it with readConcern: "majority".