MongoDB Deep Dive — Documents, Aggregation, Sharding

10. Practice Problems

These problems are mostly conceptual — MongoDB does not run inside this in-browser SQLite engine. Try each one on paper or on MongoDB Atlas (free tier), then expand the answer.

1. A collection has documents with different fields — one has phone, another has mobile. Is this allowed in MongoDB?
   একই collection-এ ভিন্ন ভিন্ন field থাকা কি অনুমোদিত?
   Show Answer

   Yes — collections are schemaless by default. But for production you usually attach a $jsonSchema validator so accidental typos like mobil get rejected. Schema flexibility is a feature, schema chaos is a bug.

   হ্যাঁ — তবে production-এ $jsonSchema validator যুক্ত করে রাখাই ভালো, যাতে ভুল field name আটকে যায়।

2. Write a Mongo command that finds all orders from Dhaka in August 2025 with total > 50,000 BDT, sorted newest first, returning only customer name and total.
   আগস্ট ২০২৫-এ ঢাকা থেকে ৫০,০০০ টাকার বেশি অর্ডার, নতুন আগে — শুধু customer name ও total।
   Show Answer

   ans2.mongo.js

   db.orders.find(
     { "customer.city": "Dhaka",
       placedAt: { $gte: ISODate("2025-08-01"),
                   $lt:  ISODate("2025-09-01") },
       total: { $gt: 50000 } },
     { "customer.name": 1, total: 1, _id: 0 }
   ).sort({ placedAt: -1 });

3. What does db.orders.updateOne({_id:1}, {status:"X"}) actually do?
   উপরের command-টি আসলে কী করে?
   Show Answer

   It replaces the entire document with {status:"X"} — every other field disappears, including customer, items, total. The correct form is {$set:{status:"X"}}. This is the most common MongoDB beginner bug.

   পুরো document overwrite হয়ে যাবে — অন্য সব field মুছে যাবে। সঠিক form: {$set:{status:"X"}}।

4. Write an aggregation that returns the top 3 customers by total spend in 2025, including their order count.
   ২০২৫ সালে সবচেয়ে বেশি খরচ করা ৩ জন customer ও তাদের order সংখ্যা।
   Show Answer

   ans4.mongo.js

   db.orders.aggregate([
     { $match: { status: "PAID",
                 placedAt: { $gte: ISODate("2025-01-01") } } },
     { $group: { _id: "$customer._id",
                 name: { $first: "$customer.name" },
                 orders: { $sum: 1 },
                 spend: { $sum: "$total" } } },
     { $sort: { spend: -1 } },
     { $limit: 3 }
   ]);

5. Why is $match usually placed at the very start of an aggregation pipeline?
   $match সাধারণত pipeline-এর শুরুতে কেন রাখা হয়?
   Show Answer

   Two reasons. (1) Index use: only stages before identity-breaking stages like $group/$unwind can use indexes. (2) Less data: every later stage processes fewer documents, so the whole pipeline gets faster. Always filter as early — and as aggressively — as possible.

   কারণ — তখনই index ব্যবহার হতে পারে, এবং পরবর্তী সব stage-এ কম document প্রসেস করতে হয়।

6. A 3-node replica set is configured with {w: "majority"}. The primary acknowledges a write to the client. Can that write be lost if the primary crashes 1 second later?
   primary acknowledge করার পরও কি write হারানো সম্ভব?
   Show Answer

   No. {w:"majority"} means the primary returned only after at least 2 of 3 nodes had the operation in their oplog. Even if the primary dies, one of the surviving secondaries already has the write and will be elected the new primary. With {w:1} the same scenario can lose the write — that is the entire trade-off.

   না — w:"majority" নিশ্চিত করে কমপক্ষে ২টি নোডে write পৌঁছেছে। তাই primary মারা গেলেও write বেঁচে যায়।

7. Why is {createdAt:1} a poor shard key for a sharded write-heavy log collection?
   log collection-এ createdAt-কে shard key বানালে সমস্যা কী?
   Show Answer

   Time keeps going up — every new document falls into the highest chunk, so all writes land on one shard while the others sit idle ("hot shard"). Use {createdAt:"hashed"} or a compound key like {tenantId:1, createdAt:1} instead.

   সব নতুন write একটিই shard-এ যায় — বাকি shard বসে থাকে। তাই hashed key বা compound key ব্যবহার করুন।

8. Design: a blogging platform. Posts have title, body, tags, author, and comments. Should comments be embedded?
   ব্লগ পোস্টে comments কি embed করা উচিত?
   Show Answer

   For a hobby blog with under a few hundred comments per post — yes, embed. Reading the post returns everything in one round trip. For a Facebook-scale system where a post can have a million comments — no: the 16 MB doc limit will be hit. Use the subset pattern: embed the most recent ~20 comments and store the rest in a separate comments collection.

9. Write a TTL index that auto-deletes documents in otp 5 minutes after creation.
   ৫ মিনিট পর OTP document-গুলো auto-delete হবে — TTL index লিখুন।
   Show Answer

   ans9.mongo.js

   db.otp.createIndex(
     { createdAt: 1 },
     { expireAfterSeconds: 300 }
   );
   // Background job removes any doc whose createdAt + 300s < now.

10. Compare the index {status:1, placedAt:-1} with {placedAt:-1, status:1} for the query find({status:"PAID"}).sort({placedAt:-1}).
    দুটি compound index-এর মধ্যে কোনটি ভালো এবং কেন?
    Show Answer

    The first one. The ESR rule: Equality, then Sort, then Range. status is the equality filter, so it goes first; placedAt is the sort, so it follows. The second index would force a scan of every placedAt just to filter status afterward.

    ESR rule অনুযায়ী — Equality (status) আগে, তারপর Sort (placedAt)। তাই প্রথমটিই সঠিক।

11. What is the difference between $lookup and a SQL JOIN? Name two.
    $lookup ও SQL JOIN-এর মধ্যে দুটি পার্থক্য বলুন।
    Show Answer

    (1) $lookup always behaves like a LEFT OUTER JOIN — it never drops the left document. (2) The matched documents come back as a nested array on the result, not as flat columns. (3) Performance can be much worse than a SQL join because Mongo has no global statistics — wise to design so most reads do not need $lookup at all.

12. A query find({tags: "apple"}) on a 10M-doc collection takes 4 seconds. What single change brings it under 50 ms?
    ১০ লক্ষ document-এর query ৪ সেকেন্ড লাগছে — কী করতে হবে?
    Show Answer

    Create an index on the array field: db.coll.createIndex({tags:1}). MongoDB automatically makes it a multikey index — one entry per array element per document — and the lookup becomes O(log n) instead of O(n).

13. In a sharded cluster, why must every unique index include the shard key?
    sharded cluster-এ unique index-এ shard key কেন বাধ্যতামূলক?
    Show Answer

    Each shard validates uniqueness only against its own data — there is no cluster-wide secondary index. If the unique field is not part of the shard key, two duplicates could legitimately live on different shards and neither shard would notice.

    প্রতিটি shard কেবল নিজের data-তে uniqueness যাচাই করতে পারে; পুরো cluster-জুড়ে নয়। তাই shard key যুক্ত না থাকলে dup detect হবে না।

14. When would you choose denormalisation (storing the same fact in two places) in MongoDB?
    কখন একই data দুই জায়গায় রাখবেন?
    Show Answer

    When the field is read 100× more than it is written, and the read needs it joined with another doc. Example: an order keeps a snapshot of customer.name at order time. Even if the user changes their name later, the historical order should still show the name on the receipt — denormalisation is correct here.

    যখন data বহুবার পড়া হয় কিন্তু খুব কম পরিবর্তিত হয় — এবং historical snapshot দরকার — তখন denormalisation যুক্তিসঙ্গত।

15. Aggregation: explode a per-order document so each line item gets its own row, then sum revenue per SKU.
    প্রতিটি line item আলাদা document বানিয়ে SKU-অনুসারে revenue বের করুন।
    Show Answer

    ans15.mongo.js

    db.orders.aggregate([
      { $unwind: "$items" },
      { $group: { _id: "$items.sku",
                  revenue: { $sum: { $multiply: ["$items.qty", "$items.price"] } } } },
      { $sort: { revenue: -1 } }
    ]);

16. In two sentences: when should you not use MongoDB?
    কখন MongoDB ব্যবহার করা উচিত নয়?
    Show Answer

    Answer: When the workload is dominated by multi-record transactions across many entities (banking ledgers, double-entry accounting), or when complex ad-hoc analytical joins across 5+ tables are the norm. A relational engine like PostgreSQL is purpose-built for those — Mongo can do them, but slower and with more application-side complexity.

    যখন বহু-entity multi-record transaction দরকার (যেমন banking) অথবা ৫+ table-এর উপর জটিল ad-hoc JOIN দরকার — তখন PostgreSQL ভালো।