HomeBytesheetsRoadmapsUI TemplatesUI ToolsStack Discussion
70 Topics
Chapter•360 Minutes

70 Progressive Questions (Easy to Advanced + Scenarios)

70 comprehensive interview questions spanning database basics, Mongoose ODM abstractions, advanced aggregation pipelines, system architecture, performance tuning, and real-world scenario challenges.

Q61 [Scenario]: How do you store and query hierarchical category tree structures (e.g., e-commerce categories) in MongoDB?

Common pattern models:

  • Parent References: Each node stores { _id, name, parent: ObjectId } (fast updates).
  • Materialized Paths: Each node stores { _id, name, path: ',Electronics,Computers,Laptops,' } (fast sub-tree regex queries matching ^,Electronics,Computers,).
  • Array of Ancestors: Each node stores { ancestors: [ObjectId1, ObjectId2] }.
Key Takeaways
  • Materialized Paths enable fast sub-tree searches via regex index prefixing.
  • Array of Ancestors facilitates fast breadcrumb rendering.
Knowledge Check

Which hierarchy modeling pattern stores ancestral paths as string paths for fast sub-tree regex searches?

Q62 [Scenario]: An API requires combining Full-Text search with strict category filtering and sorting. How do you optimize this?

Standard MongoDB $text indexes have limitations when combined with sorting and filtering. Modern best practice uses MongoDB Atlas Search (powered by Apache Lucene). Create a custom Search Index definition combining autocomplete, faceted filters, and compound relevancy scoring.

Key Takeaways
  • Use MongoDB Atlas Search for enterprise-grade text search.
  • Combines full-text search, fuzzy matching, and multi-faceted filtering.
Knowledge Check

What technology powers MongoDB Atlas Search for full-text search capabilities?

Q63 [Scenario]: You are building an IoT platform receiving 50,000 sensor telemetry readings per second. How do you model this in MongoDB?

Use native Time Series Collections (introduced in MongoDB 5.0). Define timeField and metaField. MongoDB automatically compresses time series data into optimized columnar storage formats, drastically reducing disk footprint and accelerating measurement aggregations.

Key Takeaways
  • Use MongoDB native Time Series Collections.
  • Automatically stores data in compressed columnar formats.
Knowledge Check

Which specialized collection type compresses high-frequency metric data automatically into columnar storage?

Q64 [Scenario]: Creating a new index on a 100M document collection causes production write timeouts. How do you create indexes safely?

In modern MongoDB (4.2+), indexes are built using an optimized hybrid build process that allows concurrent reads/writes. However, on massive collections, perform rolling index builds across replica set members: take Secondary nodes offline one by one, create the index locally, bring them back online, and finally step down the Primary node to build the index on it.

Key Takeaways
  • MongoDB 4.2+ uses hybrid index builds concurrently.
  • Use rolling index builds across replica sets for critical production databases.
Knowledge Check

What index creation strategy builds indexes on secondary nodes one by one to protect production workloads?

Q65 [Scenario]: An e-commerce system sells products with vastly different attributes (e.g., Laptops have CPU/RAM, Clothing has Size/Color). How do you model this?

Apply the Polymorphic Pattern alongside the Attribute Pattern. Store common fields (title, price, category) at top level, and store variant attributes inside a key-value array: attributes: [{ k: 'size', v: 'XL' }, { k: 'color', v: 'Red' }]. Index the array with a compound multikey index on { 'attributes.k': 1, 'attributes.v': 1 }.

Key Takeaways
  • The Attribute Pattern organizes varying product properties cleanly.
  • Compound multikey index { 'attributes.k': 1, 'attributes.v': 1 } targets variable product specs.
Knowledge Check

Which design pattern organizes diverse product specification fields into key-value array objects for indexability?

Q66 [Scenario]: An Express API endpoint looping through posts to fetch author details executes 101 queries for 100 posts. How do you resolve this?

This is the classic $N+1$ query problem. Resolve it by using Mongoose .populate() or a single native Aggregation $lookup stage. Alternatively, extract all author ObjectIds into an array and execute a single batch query: User.find({ _id: { $in: authorIds } }), mapping results client-side.

Key Takeaways
  • Eliminate query loops inside code.
  • Use batch $in queries or $lookup aggregation joins.
Knowledge Check

What issue occurs when executing database query requests inside a forEach loop iterating over 100 documents?

Q67 [Scenario]: Compliance requires encrypting sensitive fields (SSN, Credit Cards) such that even database administrators cannot read plain text. How do you satisfy this?

Implement Client-Side Field Level Encryption (CSFLE) or In-Use Encryption. The driver automatically encrypts sensitive document fields on the application client side before sending binary payloads to MongoDB. The database server stores strictly encrypted cipher-text and never possesses the decryption keys.

Key Takeaways
  • Client-Side Field Level Encryption (CSFLE) encrypts data on client drivers.
  • Database servers never see unencrypted plain text for CSFLE fields.
Knowledge Check

Which encryption mechanism encrypts data on client drivers BEFORE sending payloads to MongoDB?

Q69 [Scenario]: A sharded cluster reports 'Jumbo Chunk' errors and balancer failures. What causes this and how do you fix it?

A Jumbo Chunk occurs when a data chunk exceeds the maximum chunk size (default 64MB) and cannot be split because all documents share the exact same shard key value (low cardinality / field hotspotting). Resolution: Refine the shard key by adding a secondary suffix field to create a compound shard key with higher cardinality.

Key Takeaways
  • Caused by low cardinality shard keys creating indivisible chunks.
  • Refine shard keys by appending additional fields to enable chunk splits.
Knowledge Check

What causes a 'Jumbo Chunk' that cannot be split or moved by the MongoDB cluster balancer?

Q70 [Scenario]: Most users have 100 posts, but 0.01% of viral celebrity users have 10,000,000 posts. How do you design a schema that handles both efficiently without over-engineering?

Apply the Outlier Pattern. Design the schema for the 99.99% standard use case (e.g., embedding recent posts or standard document structures). Add an hasExtraData: true flag for outlier entities, routing their excess data overflow into a separate secondary overflow collection.

Key Takeaways
  • Optimize schema for standard typical use cases.
  • Use the Outlier Pattern to handle rare extreme edge cases gracefully.
Knowledge Check

Which design pattern prevents rare extreme edge-case entities from dictating an inefficient schema structure for standard users?