MongoDB for system design interviews

01Why MongoDB

• Document model — data lives as BSON documents (Binary JSON) you can nest and array freely. One round trip often loads a whole object graph.
• Flexible schema — documents in the same collection can have different fields. Validate in app code or with $jsonSchema — Mongo won't enforce a rigid table schema by default.
• Queryable NoSQL — filter, sort, project, and aggregate on any indexed field without pre-designing every access path as a GSI (unlike DynamoDB). Unindexed queries still become collection scans.

02Hands-on lab

# Detached container, port 27017, named volume for data
docker run -d --name mongo-lab \
  -p 27017:27017 \
  -v mongo-lab-data:/data/db \
  mongo:7

# Shell into the container
docker exec -it mongo-lab mongosh

use chat_app

// Drop and recreate for a clean lab
db.users.drop()
db.messages.drop()

db.users.insertMany([
  {
    _id: ObjectId("64a000000000000000000101"),
    name: "Evan",
    email: "evan@example.com",
    age: 28,
    tags: ["admin", "beta"]
  },
  {
    _id: ObjectId("64a000000000000000000102"),
    name: "Stefan",
    email: "stefan@example.com",
    address: { city: "Seattle", zip: "98101" },
    tags: ["beta"]
  }
])

db.messages.insertMany([
  {
    chat_id: 1,
    user_id: ObjectId("64a000000000000000000101"),
    content: "Hello!",
    num_attach: 0,
    created_at: ISODate("2024-08-06T10:00:00Z")
  },
  {
    chat_id: 1,
    user_id: ObjectId("64a000000000000000000102"),
    content: "What time is it?",
    num_attach: 1,
    created_at: ISODate("2024-08-06T10:05:00Z")
  },
  {
    chat_id: 2,
    user_id: ObjectId("64a000000000000000000101"),
    content: "Hey team",
    num_attach: 0,
    created_at: ISODate("2024-08-06T11:00:00Z")
  }
])

db.users.find().pretty()
db.messages.find({ chat_id: 1 }).sort({ created_at: 1 })

// npm i mongodb
import { MongoClient, ObjectId } from "mongodb";

const uri = process.env.MONGO_URI ?? "mongodb://127.0.0.1:27017";
const client = new MongoClient(uri);

async function main() {
  await client.connect();
  const db = client.db("chat_app");
  const messages = db.collection("messages");

  // Create indexes once at boot / migration
  await messages.createIndex({ chat_id: 1, created_at: -1 });
  await db.collection("users").createIndex({ email: 1 }, { unique: true });

  // Query — page of a chat thread
  const page = await messages
    .find({ chat_id: 1 })
    .sort({ created_at: -1 })
    .limit(20)
    .project({ content: 1, user_id: 1, created_at: 1, _id: 0 })
    .toArray();

  // Atomic patch
  await messages.updateOne(
    { _id: new ObjectId("...") },
    { $set: { content: "Hello!!" }, $inc: { edit_count: 1 } }
  );

  console.log(page);
  await client.close();
}

main().catch(console.error);

03The data model

• _id — unique primary key per document; auto-generated ObjectId if omitted (12-byte, roughly time-sortable).
• BSON types — String, Number (Int32/Int64/Double/Decimal128), Boolean, Date, ObjectId, Array, Embedded Document, BinData, Null.
• 16 MB limit — maximum document size; critical when embedding arrays — hard ceiling, not a soft guideline.

db.createCollection("users", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["email", "name"],
      properties: {
        email: { bsonType: "string", pattern: "^.+@.+\\..+
quot; },
        name: { bsonType: "string", minLength: 1 },
        age: { bsonType: "int", minimum: 0 },
        tags: { bsonType: "array", items: { bsonType: "string" } }
      }
    }
  },
  validationAction: "error" // or "warn" while migrating
})

04CRUD operations

// Create
db.messages.insertOne({
  chat_id: 1,
  user_id: ObjectId("64a000000000000000000101"),
  content: "Hello!",
  created_at: new Date()
})

db.messages.insertMany([
  { chat_id: 1, user_id: ObjectId("64a000000000000000000102"), content: "What time is it?" },
  { chat_id: 2, user_id: ObjectId("64a000000000000000000101"), content: "Hey team" }
])

// Read
db.messages.find({ chat_id: 1 })
db.messages.findOne({ user_id: ObjectId("64a000000000000000000101") })

// Update — $set patches; never replace unless you mean it
db.messages.updateOne(
  { _id: ObjectId("...") },
  { $set: { content: "Hello!!" }, $inc: { edit_count: 1 } }
)

// Array operators
db.users.updateOne(
  { email: "evan@example.com" },
  { $addToSet: { tags: "mentor" }, $pull: { tags: "beta" } }
)

// Upsert — idempotent worker writes
db.sessions.updateOne(
  { session_id: "abc" },
  { $set: { last_seen: new Date() }, $setOnInsert: { created_at: new Date() } },
  { upsert: true }
)

// Delete
db.messages.deleteMany({ chat_id: 2 })

05Querying

// Comparison & logical
db.messages.find({
  chat_id: 1,
  created_at: { $gte: ISODate("2024-08-01") },
  content: { $regex: /^Hello/ }
})

// Array operators
db.users.find({ tags: { $in: ["admin"] } })
db.users.find({ tags: { $all: ["admin", "beta"] } })

// Nested fields — dot notation
db.users.find({ "address.city": "Seattle" })

// Projection — return only needed fields (saves bandwidth + deserialization)
db.messages.find(
  { chat_id: 1 },
  { projection: { content: 1, user_id: 1, _id: 0 } }
)

// Sort + offset pagination (OK for small offsets)
db.messages.find({ chat_id: 1 })
  .sort({ created_at: -1 })
  .limit(20)
  .skip(40)

// Keyset pagination (preferred at scale — no deep skip)
db.messages.find({
  chat_id: 1,
  created_at: { $lt: ISODate("2024-08-06T10:05:00Z") }
}).sort({ created_at: -1 }).limit(20)

06Indexes

// Single-field
db.users.createIndex({ email: 1 }, { unique: true })

// Compound — order matters for { chat_id, created_at } queries
db.messages.createIndex({ chat_id: 1, created_at: -1 })

// Multikey — automatic on array fields
db.users.createIndex({ tags: 1 })

// TTL — expire sessions after 24h
db.sessions.createIndex({ created_at: 1 }, { expireAfterSeconds: 86400 })

// Partial — index only active docs (smaller, cheaper)
db.orders.createIndex(
  { user_id: 1, created_at: -1 },
  { partialFilterExpression: { status: { $eq: "open" } } }
)

// Verify query plan
db.messages.find({ chat_id: 1 }).sort({ created_at: -1 }).explain("executionStats")
// Look for: stage: "IXSCAN" not "COLLSCAN"

• Compound index prefix — index on { a, b, c } supports queries on a; a+b; a+b+c — not b alone.
• ESR rule — Equality fields, then Sort, then Range for compound index design.
• Text / geospatial — specialized indexes for full-text ($text) and $near queries.
• Covered queries — if projection fields ⊆ index keys, Mongo can answer from the index alone.

07Schema design

// Embed — product with a few reviews (read together)
db.products.insertOne({
  sku: "ABC-123",
  name: "Widget",
  reviews: [
    { user: "Evan", rating: 5, text: "Great" },
    { user: "Stefan", rating: 4, text: "Good" }
  ]
})

// Reference — messages by chat (unbounded)
db.messages.insertOne({
  chat_id: 1,
  user_id: ObjectId("64a000000000000000000101"),
  content: "Hi"
})

// Join at read time ($lookup — left outer join)
db.orders.aggregate([
  { $match: { status: "shipped" } },
  { $lookup: {
      from: "users",
      localField: "user_id",
      foreignField: "_id",
      as: "buyer"
  }},
  { $unwind: "$buyer" }
])

08Aggregation pipeline

// Top posters per chat in the last 7 days
db.messages.aggregate([
  { $match: {
      created_at: { $gte: new Date(Date.now() - 7 * 86400000) }
  }},
  { $group: {
      _id: { chat_id: "$chat_id", user_id: "$user_id" },
      count: { $sum: 1 },
      last_msg: { $max: "$created_at" }
  }},
  { $sort: { count: -1 } },
  { $limit: 10 },
  { $project: {
      chat_id: "$_id.chat_id",
      user_id: "$_id.user_id",
      message_count: "$count",
      last_msg: 1,
      _id: 0
  }}
])

// Faceted search-style counts in one round trip
db.products.aggregate([
  { $match: { category: "shoes" } },
  { $facet: {
      byBrand: [{ $group: { _id: "$brand", n: { $sum: 1 } } }],
      priceStats: [{ $group: { _id: null, avg: { $avg: "$price" } } }],
      sample: [{ $limit: 5 }]
  }}
])

09Consistency

// Durable write
db.orders.insertOne(
  { user_id: 123, total: 4999 },
  { writeConcern: { w: "majority", j: true } }
)

// Strong read from primary
db.orders.findOne(
  { _id: orderId },
  { readConcern: { level: "majority" } }
)

// Analytics — stale OK, offload primary
db.messages.find({ chat_id: 1 })
  .readPref("secondaryPreferred")

10Replica sets

• Primary — all writes; default read target.
• Secondary — async replication via oplog; serve reads with readPreference.
• Arbiter — vote only, no data; cheap tiebreaker (less common now — prefer a data-bearing third member).

// Hands-on: init a 1-node replica set (needed for transactions & change streams locally)
// docker run ... mongo:7 --replSet rs0
// then in mongosh:
rs.initiate({
  _id: "rs0",
  members: [{ _id: 0, host: "localhost:27017" }]
})
rs.status()

11Sharding

// Enable sharding on database
sh.enableSharding("chat_app")

// Hashed user_id — even write spread (Dynamo-like)
sh.shardCollection("chat_app.events", { user_id: "hashed" })

// Range-based for time-series / locality
sh.shardCollection("chat_app.logs", { created_at: 1, _id: 1 })

12Transactions

// mongosh / driver session API
const session = db.getMongo().startSession()
session.startTransaction()
try {
  const orders = session.getDatabase("shop").orders
  const inventory = session.getDatabase("shop").inventory
  orders.insertOne({ sku: "ABC", qty: 1 }, { session })
  inventory.updateOne(
    { sku: "ABC", stock: { $gte: 1 } },
    { $inc: { stock: -1 } },
    { session }
  )
  session.commitTransaction()
} catch (e) {
  session.abortTransaction()
  throw e
} finally {
  session.endSession()
}

13Change streams

const changeStream = db.messages.watch([
  { $match: { operationType: { $in: ["insert", "update"] } } }
], { fullDocument: "updateLookup" })

changeStream.on("change", (event) => {
  // Sync Elasticsearch, invalidate cache, push webhook
  console.log(event.operationType, event.fullDocument)
  // Persist event._id / resume token for crash recovery
})

• Search sync — stream → worker → Elasticsearch / Atlas Search
• Cache invalidation — stream → delete Redis keys for changed docs
• Fan-out — stream → queue → notification service

14Security and operations

• Auth — enable access control; SCRAM users / Atlas IAM-style roles; never expose an unauthenticated mongod to the internet.
• TLS — encrypt in transit; Atlas does this by default.
• Encryption at rest — WiredTiger encrypted storage / Atlas encryption; key management via KMS on cloud.
• Network — VPC peering / private endpoints on Atlas; bind IP allowlists.
• Backup — Atlas continuous backup; self-hosted via filesystem snapshots or mongodump.

15Cost and performance levers

16MongoDB in an interview

17Document modeling drills

18Interview Q&A by level

19Wrapping up