Learning MongoDB - Production-Grade E-Commerce Document Database Case Study

#Introduction

Congratulations — you've completed 19 episodes, from setup, CRUD, advanced queries, schema design, aggregation, indexing, transactions, replica sets, sharding, security, backups, to monitoring. Now it's time for the final proof: tying everything together into one production-grade architecture. Episode 20 is an e-commerce case study uniting all the knowledge: designing schemas for users & auth, the product catalog, orders & inventory, and analytics, then the deployment architecture with replica sets, TLS, backups, and monitoring, closing with a production readiness checklist and final reflection.

#Users & Auth

#User Schema with Embedded Addresses

A user holds a profile and a list of addresses. Because the number of addresses per user is small and always read together with the profile, we embed the addresses as an array (the one-to-few pattern from episode 7):

{
  "_id": ObjectId("66aaaaaaaaaaaaaaaaaaaaaaaa"),
  "email": "siti@example.com",
  "name": "Siti Rahma",
  "role": "customer",
  "status": "active",
  "nationalIdEncrypted": BinData(0, "...ciphertext..."),
  "addresses": [
    { "label": "rumah", "street": "Jl. Merdeka No. 10", "city": "Jakarta", "zip": "10110" }
  ],
  "createdAt": ISODate("2026-01-15T09:00:00Z")
}

Notice nationalIdEncrypted — the national ID is stored as ciphertext from CSFLE (episode 17): encrypted on the application side, so even the server can't read it.

#User Data Protection

• Unique index on email — guarantees no duplicate accounts at the database level.
• SCRAM-SHA-256 for application user authentication; custom roles limit each service's privileges (the auth service can write, the billing service is read-only).
• Partial index { email: 1 } on documents with status: "active" — soft-deleted users don't lock their email.

db.users.createIndex({ email: 1 }, { unique: true })
db.users.createIndex({ email: 1 }, { unique: true, partialFilterExpression: { status: "active" } })

#Product Catalog

#Flexible Schema for Dynamic Attributes

Products have highly varied attributes: fashion has size and color, electronics has specs. This is the perfect job for a flexible schema — dynamic attributes are stored as an embedded document (episode 7), so each category is free to determine its own structure:

{
  "_id": ObjectId("66bbbbbbbbbbbbbbbbbbbbbbbb"),
  "name": "Laptop Gaming 15",
  "category": "elektronik",
  "price": NumberDecimal("15000000"),
  "stock": 5,
  "tags": ["best-seller", "baru"],
  "specs": { "ram": "16GB", "storage": "512GB SSD" }
}

#Indexes for Search and Flash Sales

db.products.createIndex({ category: 1, price: 1 })
db.products.createIndex({ name: "text", description: "text" })
db.flashSales.createIndex({ createdAt: 1 }, { expireAfterSeconds: 3600 })

• Compound index { category: 1, price: 1 } — following the ESR rule (episode 12) for the most frequently run "electronics products at a certain price" query.
• Text index — full-text search on name and description (episode 11).
• TTL index on the flashSales collection — flash sale promo documents are automatically deleted after one hour, without manual cron jobs.

#Orders & Inventory

#Stock Consistency with Transactions

Creating an order while decrementing stock must be atomic — if stock gets cut but the order fails, or vice versa, your store is a mess. The solution: a multi-document ACID transaction (episode 14):

Create an order and decrement stock atomically (Node.js)

const session = client.startSession();
session.startTransaction();
try {
  await products.updateOne({ _id: productId, stock: { $gte: qty } }, { $inc: { stock: -qty } }, { session });
  await orders.insertOne(
    { userId, items: [{ productId, qty, priceAtPurchase }], total, status: "pending", createdAt: new Date() },
    { session }
  );
  await session.commitTransaction();
} catch (err) {
  await session.abortTransaction();
} finally {
  await session.endSession();
}

Two clever details: the stock: { $gte: qty } filter ensures the stock decrement only happens if supply is sufficient (otherwise the transaction is aborted), and priceAtPurchase is a price snapshot (episode 7) — the order still records the price at purchase time even if the price changes later.

#Real-time Notifications with Change Streams

After an order is created, its status changes: pending, paid, shipped, delivered. To notify the user in real time, we attach a change stream (episode 18) to the orders collection:

Change stream for order status notifications

const changeStream = orders.watch([
  { $match: { operationType: "update", "updateDescription.updatedFields.status": { $exists: true } } }
]);
changeStream.on("change", (event) => {
  notifyUser(event.documentKey._id, event.updateDescription.updatedFields.status);
});

Every time an order's status changes, the application sends a notification to the user — without polling, with almost no latency. This is also the data source for pipelines syncing to a search engine or data warehouse.

#Analytics

#Aggregation for Daily Reports

With the aggregation pipeline (episodes 9 and 10), analytics needs are fulfilled in centralized queries. Daily sales reports per category:

db.orders.aggregate([
  { $match: { status: "paid" } },
  { $unwind: "$items" },
  { $addFields: { day: { $dateToString: { format: "%Y-%m-%d", date: "$createdAt" } } } },
  { $group: { _id: { day: "$day", category: "$items.category" }, revenue: { $sum: { $multiply: ["$items.priceAtPurchase", "$items.qty"] } } } },
  { $sort: { "_id.day": 1 } }
])

#Dashboard in One Query with $facet

A dashboard page needs several summaries at once — total revenue, best-selling products, and recent orders. $facet runs them in one consistent query:

db.orders.aggregate([
  { $match: { status: "paid" } },
  { $facet: {
      "summary": [{ $group: { _id: null, totalRevenue: { $sum: "$total" } } }],
      "topProducts": [{ $unwind: "$items" }, { $group: { _id: "$items.productId", qty: { $sum: "$items.qty" } } }, { $sort: { qty: -1 } }, { $limit: 10 }],
      "recent": [{ $sort: { createdAt: -1 } }, { $limit: 5 }]
  } }
])

#Deployment Architecture

3-Member Replica Set (rs0): Primary writes + reads, Secondary reads for reports + failover candidate
Security layer: SCRAM-SHA-256 for all users, RBAC role per service, TLS on all connections, CSFLE for sensitive fields
Operational automation: mongodump every 6 hours + monthly restore test, Prometheus/Grafana + alerting, profiler slowms 100

#Production Readiness Checklist

• Authentication active (authorization: enabled) and no default users.
• Minimal RBAC: the application doesn't run as root.
• TLS active for all connections and between nodes.
• Automatic backups scheduled and restore tests proven successful.
• Monitoring with alerts for CPU, memory, connections, and replication lag.
• Indexes verified with explain() to confirm IXSCAN on primary queries.
• Schema validation active for important collections.
• Maintenance windows scheduled for routine compact/reIndex.
• Tested failover plan (replica set) and documented restore scenarios.

#Conclusion

Congratulations — you've completed the entire Learning MongoDB journey from zero to production-grade. In this closing episode you tied everything together: a users schema with embedded addresses and CSFLE, a product catalog with flexible attributes and compound plus TTL indexes, orders & inventory with ACID transactions and change streams, and analytics with the aggregation pipeline and $facet. You also put together a three-member replica set deployment with TLS, automatic backups, and Prometheus/Grafana monitoring, plus a ready-to-use production readiness checklist.

Key takeaways:

• A good schema follows access patterns: embed what's read together, reference what's large.
• Stock and order consistency is guaranteed with multi-document transactions.
• Change streams turn the database into a source of real-time events.
• One aggregation query can replace dozens of separate calls.
• Production deployment = replica set + TLS + RBAC + tested backups + monitoring.
• A flexible schema isn't an excuse to design lazily — it's a reason to be more disciplined.

Thank you for sticking with it to the end. You're no longer just someone who "knows MongoDB" — you have a complete thinking framework: from writing queries, designing schemas, securing, monitoring, to building production systems. Now it's time to take this knowledge to your own projects. Start small, verify with explain(), and let every decision be driven by data — exactly as you've learned throughout this series. Happy building!