MongoDB

01The idea: documents instead of rows

Think of a relational database as a set of spreadsheets that you join together, and MongoDB as a filing cabinet where each folder holds everything about one thing. A document is a BSON object (binary JSON with extra types such as dates, decimals and ObjectId). Documents live in collections, and collections live in a database. Every document has a unique _id. Documents in one collection do not have to share the same fields, but in practice they should, and you enforce it with a JSON Schema validator. The maximum size of one document is 16 MB, which is a hint: documents are for bounded data, not for endless lists.

• BSON: the binary format MongoDB stores; it supports types JSON lacks, such as Date and Decimal128.
• Collection: a group of documents, roughly like a table.
• ObjectId: the default 12-byte _id, roughly ordered by creation time.

02Modelling: embed or reference

The core design question is whether related data goes inside the parent document (embed) or in its own collection with an id pointing to it (reference). Embed when the child belongs to the parent, is read together with it, and has a bounded size: an order and its line items, a user and their addresses. Reference when the child is shared, grows without limit, or is updated independently: comments on a popular post, products referenced by many orders. The rule of thumb from MongoDB's own guidance is “data that is accessed together should be stored together”. Design from your queries backwards: list the screens and API calls first, then shape documents so each one is served by one read.

1// One order document: line items embedded, customer referenced
2{
3  _id: ObjectId("665f1c2a9b1e8a0012345678"),
4  customerId: ObjectId("665f1b009b1e8a0011112222"),
5  status: "paid",
6  total: NumberDecimal("59.90"),
7  items: [
8    { sku: "TSHIRT-M", qty: 2, price: NumberDecimal("19.95") },
9    { sku: "CAP-01", qty: 1, price: NumberDecimal("20.00") }
10  ],
11  createdAt: ISODate("2026-11-05T10:00:00Z")
12}

03Queries, indexes and the ESR rule

You query with filter documents ({ status: "paid" }) and operators such as $gt, $in and $elemMatch. Without an index, MongoDB scans every document (a COLLSCAN). Indexes are B-trees, just like in SQL databases, and compound indexes follow the ESR rule: put fields you match by Equality first, then fields you Sort by, then fields you filter by Range. An index on { customerId: 1, createdAt: -1 } serves “latest orders of this customer” perfectly. Always check a query with explain("executionStats") and compare totalDocsExamined with nReturned; if the first is much bigger, the index is wrong or missing.

1db.orders.createIndex({ customerId: 1, status: 1, createdAt: -1 })
2 
3db.orders
4  .find({ customerId: id, status: "paid", createdAt: { $gte: since } })
5  .sort({ createdAt: -1 })
6  .limit(20)
7  .explain("executionStats")

04The aggregation pipeline

Aggregation is MongoDB's answer to GROUP BY and reporting. A pipeline is an array of stages, and each stage transforms the stream of documents and passes it on, like an assembly line. $match filters (put it first so it can use an index), $group computes totals, $sort orders, $project reshapes, $lookup joins another collection, and $unwind turns an array into one document per element. Pipelines are powerful but can get heavy: a $group over millions of documents uses memory, and stages that exceed 100 MB spill to disk. Keep $match and $project early to shrink the data before expensive stages.

1db.orders.aggregate([
2  { $match: { status: "paid", createdAt: { $gte: ISODate("2026-10-01") } } },
3  { $unwind: "$items" },
4  { $group: {
5      _id: "$items.sku",
6      units: { $sum: "$items.qty" },
7      revenue: { $sum: { $multiply: ["$items.qty", "$items.price"] } }
8  } },
9  { $sort: { revenue: -1 } },
10  { $limit: 10 }
11])

05Replica sets, write concern and transactions

A replica set is a group of mongod servers holding the same data: one primary takes writes, secondaries copy its operation log (the oplog). If the primary dies, the remaining members elect a new one within seconds. Write concern says how many members must confirm a write; the default since MongoDB 5.0 is “majority”, which means an acknowledged write survives a failover. Read concern and read preference control what you read and from where. Multi-document ACID transactions exist (replica sets since 4.0, sharded clusters since 4.2), but they cost performance; a good document model needs them rarely, because a single-document write is already atomic.

• Use at least three data-bearing members in production, spread across zones.
• Connect with the full replica set connection string so drivers find the new primary on failover.
• Reading from secondaries can return slightly stale data; use it only where that is acceptable.

06Using it from an application

Official drivers exist for Node.js, PHP, Python, Go, Java and more. In Node.js many teams add Mongoose for schemas and validation, but the native driver is fine and thinner. Create one client per process and reuse it: the client keeps a connection pool. Validate input at the edge, keep money in Decimal128 (never floating point), and store dates as real Date values in UTC. Turn on schema validation at the collection level so a buggy deploy cannot write garbage.

1import { MongoClient } from "mongodb";
2 
3const client = new MongoClient(process.env.MONGODB_URI!); // reuse per process
4const orders = client.db("shop").collection("orders");
5 
6export async function latestOrders(customerId: ObjectId) {
7  return orders
8    .find({ customerId }, { projection: { items: 0 } })
9    .sort({ createdAt: -1 })
10    .limit(20)
11    .toArray();
12}

07WiredTiger: how storage really works

WiredTiger is MongoDB's storage engine. It uses document-level concurrency control, so two writers only block each other when they touch the same document. Data and indexes are B-trees compressed on disk (snappy by default, zstd optional). WiredTiger keeps a cache in RAM, by default about 50% of (RAM minus 1 GB); performance depends on the working set (frequently used documents plus indexes) fitting there. Writes go to a journal first and are checkpointed to data files periodically, so a crash recovers from the last checkpoint plus the journal. When the working set does not fit, you see cache eviction pressure and disk reads dominating latency, which is the moment to add RAM, trim indexes or shard.

• Watch db.serverStatus().wiredTiger.cache for dirty and evicted bytes.
• Indexes must fit in RAM for fast queries; check sizes with db.collection.stats().

08Sharding and choosing a shard key

Sharding splits a collection across several replica sets. A router (mongos) sends each query to the shards that own the relevant ranges of the shard key. The shard key decides everything: it should have high cardinality, spread writes evenly and appear in most queries. A monotonically increasing key such as a timestamp or ObjectId sends all inserts to one shard (a hot shard); hashed sharding fixes the spread but makes range queries scatter to every shard. A compound key such as { tenantId: 1, createdAt: 1 } often works well for multi-tenant apps. Since 5.0 you can reshard a collection online and since 6.0 the balancer works on data size rather than chunk count, but resharding is still expensive, so choose carefully.

1sh.enableSharding("shop")
2sh.shardCollection("shop.events", { tenantId: 1, createdAt: 1 })
3 
4// Queries that include tenantId are targeted to one shard
5db.events.find({ tenantId: "t_42", createdAt: { $gte: since } })

09Consistency knobs: write concern, read concern, causal sessions

MongoDB lets you choose consistency per operation. Write concern w: "majority" waits until most members have the write, so it survives failover; w: 1 is faster but a write can be rolled back if the primary dies before replicating. Read concern "majority" returns only data acknowledged by a majority, "linearizable" gives the strongest guarantee for single-document reads at higher cost, and "snapshot" is used inside transactions. Causally consistent sessions guarantee that a client reads its own writes even when reading from secondaries. The mistake is mixing settings without thinking: writing with w: 1 and reading from secondaries can show users data that later disappears.

10Change streams, TTL and time series

Change streams let an application subscribe to inserts, updates and deletes on a collection, database or cluster, built on the oplog. They are resumable with a resume token, which makes them a solid source for syncing a search index or cache, or for publishing events (often combined with an outbox pattern). TTL indexes delete documents automatically after a time, useful for sessions and temporary tokens. Time series collections store measurements efficiently in buckets, with automatic compression, which suits metrics and IoT data. Atlas also adds Atlas Search (Lucene-based full text) and Vector Search, and recent Community and Enterprise releases began bringing search and vector search to self-managed deployments.

1// Expire sessions 24 hours after createdAt
2db.sessions.createIndex({ createdAt: 1 }, { expireAfterSeconds: 86400 })
3 
4// React to new paid orders
5const stream = db.orders.watch([{ $match: { "fullDocument.status": "paid" } }],
6  { fullDocument: "updateLookup" })