Mobile App Now Available

Master Interviews
Anywhere, Anytime

Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.

Get it on

Google Play

4.9/5 Rating on Store

Company page Subject page

Google · MongoDB/NoSQL

Google MongoDB/NoSQL interview questions

Practice MongoDB/NoSQL questions specifically asked in Google interviews – ideal for online test preparation, technical rounds and final HR discussions.

Company: GoogleSubject: MongoDB/NoSQL52 questions in this page

Quick overview

Questions

Tagged for this company + subject

Company

Google

View company-wise questions

Subject

MongoDB/NoSQL

Explore topic-wise practice

Google · MongoDB/NoSQL questions (52)

Go through each question and its explanation. Use this page for targeted revision just before your Google MongoDB/NoSQL round.

Back to Google page•View all MongoDB/NoSQL questions

1. Which characteristic is MOST important when choosing a shard key?

Difficulty: HardType: MCQTopic: Shard Key

High cardinality, meaning many distinct values, is crucial for a good shard key because it enables even distribution of data across shards. A shard key with low cardinality can lead to unbalanced shards where some shards hold much more data than others. While the shard key field must be indexed, this is automatically handled by MongoDB when you shard the collection. The field does not need to be unique or a string. The most important consideration is ensuring the shard key provides good data distribution and supports your query patterns.

Example code

// Good shard key - high cardinality
sh.shardCollection("db.orders", { userId: 1, orderDate: 1 })
// Many unique combinations of userId and orderDate

// Poor shard key - low cardinality
sh.shardCollection("db.orders", { status: 1 })
// Only a few status values like 'pending', 'completed'
// Results in uneven distribution

Continue your preparation

For complete preparation, combine this company + subject page with full company-wise practice and subject-wise practice. You can also explore other companies and topics from the links below.

Quick navigation:Google company page•MongoDB/NoSQL subject page•All companies•All subjects

2. Explain geospatial indexes in MongoDB. What are the differences between 2d and 2dsphere indexes?

Difficulty: MediumType: SubjectiveTopic: Indexing

Geospatial indexes in MongoDB enable efficient queries on location data, allowing you to find documents based on geographic coordinates. MongoDB supports two types of geospatial indexes: 2d for flat geometries and 2dsphere for spherical geometries. 2d indexes are designed for flat, two-dimensional coordinate systems like maps. They work with legacy coordinate pairs represented as arrays of two numbers. 2d indexes support queries within rectangles, circles, and polygons on a flat plane. Use 2d indexes when your data represents points on a flat map, such as game positions or floor plans. 2dsphere indexes work with spherical geometries that model the Earth's surface. They use GeoJSON format to represent points, lines, and polygons considering the Earth as an oblate spheroid. This provides accurate distance calculations for geographic coordinates like GPS locations. 2dsphere indexes support queries like finding locations within a certain distance, within a polygon, or along a route. GeoJSON format specifies geometry types and coordinates. A point is defined with type Point and coordinates as longitude then latitude. A polygon is defined with type Polygon and an array of coordinate arrays forming closed rings. MongoDB provides geospatial query operators like dollar near for proximity queries, dollar geoWithin for area queries, and dollar geoIntersects for intersection queries. Geospatial queries are essential for location-based applications like finding nearby restaurants, delivery routing, ride-sharing services, or real estate searches. The 2dsphere index is recommended for most geographic applications because it accounts for the Earth's curvature and provides more accurate results.

Example code

// Create 2dsphere index for GPS coordinates
db.places.createIndex({ location: "2dsphere" })

// Insert location using GeoJSON
db.places.insertOne({
  name: "Coffee Shop",
  location: {
    type: "Point",
    coordinates: [-73.97, 40.77]  // [longitude, latitude]
  }
})

// Find places near a point (within 1000 meters)
db.places.find({
  location: {
    $near: {
      $geometry: {
        type: "Point",
        coordinates: [-73.98, 40.76]
      },
      $maxDistance: 1000  // meters
    }
  }
})

// Find places within a polygon
db.places.find({
  location: {
    $geoWithin: {
      $geometry: {
        type: "Polygon",
        coordinates: [[[-74, 40], [-73, 40], [-73, 41], [-74, 41], [-74, 40]]]
      }
    }
  }
})

3. What are the essential best practices for deploying MongoDB in production environments?

Difficulty: HardType: SubjectiveTopic: Production Ops

Deploying MongoDB in production requires careful planning and adherence to best practices to ensure reliability, performance, and security. These practices span architecture, configuration, operations, and monitoring. First, always use replica sets even for single-server deployments. Replica sets provide high availability through automatic failover and data redundancy. Use at least three data-bearing members across different availability zones or data centers for maximum resilience. Configure appropriate write and read concerns based on your durability requirements. Second, properly size your hardware and infrastructure. Ensure your working set fits in RAM for optimal performance. Working set is the frequently accessed data and indexes. MongoDB performance degrades significantly when the working set exceeds available memory. Use SSD storage for data directories to improve I/O performance. Allocate sufficient CPU cores for concurrent operations. Third, implement comprehensive monitoring and alerting. Track key metrics including query performance, replication lag, connection counts, memory usage, disk I/O, and error rates. Set up alerts for abnormal conditions like high replication lag, low disk space, or connection saturation. Use MongoDB Cloud Manager, Ops Manager, or integrate with tools like Prometheus and Grafana. Fourth, establish backup and disaster recovery procedures. Implement automated backups with point-in-time recovery capability. Test restore procedures regularly to verify backups work. Store backups in a different geographic location. Document recovery time objectives and recovery point objectives, and ensure procedures meet these targets. Fifth, implement security hardening. Enable authentication and authorization, use TLS for all connections, implement network security through firewalls and VPNs, enable encryption at rest for sensitive data, configure auditing for compliance, and keep MongoDB updated with security patches. Sixth, optimize for your workload. Create appropriate indexes based on query patterns, but avoid over-indexing which slows writes. Use covered queries where possible. In sharded clusters, choose shard keys carefully to ensure even distribution and support common queries. Seventh, manage connection pooling properly. Configure appropriate connection pool sizes in drivers to balance concurrency with resource usage. Monitor connection counts and adjust pool sizes if needed. Finally, document your deployment architecture, configurations, and operational procedures for your team.

Example code

// Production configuration example (mongod.conf)

// Network settings
net:
  port: 27017
  bindIp: 10.0.0.5,127.0.0.1  // Private IP + localhost
  maxIncomingConnections: 1000
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem

// Security
security:
  authorization: enabled
  keyFile: /etc/mongodb/keyfile  // Replica set auth

// Storage
storage:
  dbPath: /data/mongodb
  engine: wiredTiger
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8  // 50% of RAM
      journalCompressor: snappy
    collectionConfig:
      blockCompressor: snappy

// Replication
replication:
  replSetName: "production-rs"
  oplogSizeMB: 10240  // 10GB oplog

// System resource limits
processManagement:
  fork: true
  pidFilePath: /var/run/mongodb/mongod.pid

// Operational logging
systemLog:
  destination: file
  path: /var/log/mongodb/mongod.log
  logAppend: true
  logRotate: reopen

// Profiling (disable in production, enable when troubleshooting)
operationProfiling:
  mode: slowOp
  slowOpThresholdMs: 100

// Best practices checklist:
// ✓ Replica set with 3+ members
// ✓ Authentication and authorization enabled
// ✓ TLS encryption
// ✓ Monitoring and alerting configured
// ✓ Automated backups
// ✓ Proper hardware sizing (working set in RAM)
// ✓ Connection limits configured
// ✓ Regular security updates
// ✓ Documented procedures

5. Explain the trade-offs between embedding documents versus referencing in MongoDB. When should you use each approach?

Difficulty: HardType: SubjectiveTopic: Data Modeling

Embedding and referencing are two fundamental approaches to modeling relationships in MongoDB, each with distinct advantages and trade-offs. The choice between them significantly impacts performance, data integrity, and application complexity. Embedding stores related data within the same document. For example, storing a user's address directly inside the user document. Advantages include better read performance because all data is retrieved in a single query, atomicity where updates to embedded data are atomic, and locality where related data is stored together on disk. Disadvantages of embedding include document size limits because documents cannot exceed 16 MB, data duplication when the same embedded data needs to appear in multiple parent documents, and unbounded growth problems when arrays can grow indefinitely. Embedding also makes it harder to query embedded data independently. Referencing stores related data in separate documents and uses references like foreign keys to link them. For example, storing user ID in order documents to reference the user collection. Advantages include no duplication because shared data exists once, ability to query referenced data independently, and no size limits on the relationship. Disadvantages of referencing include requiring multiple queries or dollar lookup to retrieve related data, no atomic updates across documents outside transactions, and increased complexity in application code to manage relationships. Use embedding when you have one-to-one relationships, one-to-few relationships with a small bounded number of embedded documents, data that is always accessed together, data that rarely changes, or when atomic updates to related data are critical. For example, embed user addresses, order line items, or blog post comments. Use referencing when you have one-to-many relationships with unbounded growth, many-to-many relationships, data that is frequently accessed independently, data that changes frequently and needs to be shared, or when document size approaches limits. For example, reference users from orders, products from categories, or students from courses. In practice, hybrid models are common. You might embed frequently accessed fields for performance while referencing complete related documents. For example, embed author name and ID in blog posts for display, but reference the full author document for profile pages.

Example code

// EMBEDDING APPROACH
// Good for: one-to-one, one-to-few, always accessed together
{
  _id: 1,
  name: "John Doe",
  email: "john@example.com",
  address: {  // Embedded document
    street: "123 Main St",
    city: "New York",
    zip: "10001"
  },
  orders: [  // Embedded array (bounded)
    { orderId: 1, item: "Laptop", amount: 999 },
    { orderId: 2, item: "Mouse", amount: 29 }
  ]
}
// Single query gets everything
db.users.findOne({ _id: 1 })

// REFERENCING APPROACH
// Good for: one-to-many (unbounded), many-to-many, independent access

// Users collection
{
  _id: 1,
  name: "John Doe",
  email: "john@example.com"
}

// Orders collection (references user)
{
  _id: 101,
  userId: 1,  // Reference to user
  items: [...],
  total: 1500
}

// Requires multiple queries or $lookup
const user = db.users.findOne({ _id: 1 })
const orders = db.orders.find({ userId: 1 })

// HYBRID APPROACH
// Embed frequently used data, reference full document
{
  _id: 101,
  author: {  // Embed key info
    id: 1,
    name: "John Doe"
  },
  title: "MongoDB Guide",
  content: "..."
}
// Get author details when needed
db.authors.findOne({ _id: 1 })

6. What steps and considerations are involved in migrating a large production database from a single MongoDB instance to a sharded cluster with minimal downtime?

Difficulty: HardType: SubjectiveTopic: Production Ops

Migrating a production database to a sharded cluster is a complex operation requiring careful planning, testing, and execution to minimize downtime and ensure data integrity. The process involves multiple phases and careful coordination. Phase one is planning and preparation. First, analyze your current workload, data size, growth rate, and query patterns. Identify the optimal shard key based on query patterns, data distribution, and cardinality. A poor shard key choice cannot be changed without rebuilding, so this is critical. Second, design your target sharded cluster architecture including the number of shards, shard replica sets, config servers, and mongos routers. Third, prepare the infrastructure by provisioning servers for config servers, shards, and mongos routers. Configure networking, security, and monitoring. Fourth, test the entire migration process in a staging environment with a copy of production data. Verify application compatibility with mongos, test failover scenarios, and measure performance. Phase two is deploying the sharded infrastructure. Deploy config servers as a replica set, deploy each shard as a replica set, deploy mongos routers, and configure authentication and TLS. At this point, the sharded cluster is empty and ready to receive data. Phase three is the actual migration with minimal downtime. The recommended approach uses MongoDB's live migration capabilities. First, add your existing replica set as the first shard in the cluster. Second, enable sharding on the database using sh.enableSharding. Third, shard the collections using sh.shardCollection with your chosen shard key. At this point, all data is on one shard. Fourth, add additional empty shards to the cluster. Fifth, the balancer automatically begins migrating chunks to new shards, distributing data. Sixth, update application connection strings to use mongos instead of direct replica set connections. Use connection pooling and retry logic for resilience. During migration, monitor chunk migration progress, watch for any application errors or timeouts, verify data distribution across shards is balanced, and monitor performance metrics on all components. Phase four is post-migration validation. Verify all data migrated successfully by comparing document counts, test application functionality thoroughly including read and write operations, monitor performance and optimize indexes if needed, and establish backup and disaster recovery procedures for the sharded cluster. Key considerations include choosing an optimal shard key, extensive testing in staging before production, having a rollback plan, communicating with stakeholders about migration timeline, and planning for increased operational complexity of managing a sharded cluster.

Example code

// MIGRATION PROCESS

// Current: Single replica set
// Target: 3-shard cluster

// Step 1: Deploy infrastructure
// - Config servers (3-member replica set)
// - Shard 1 (existing replica set)
// - Shard 2 (new 3-member replica set)
// - Shard 3 (new 3-member replica set)
// - Mongos routers (2+ instances)

// Step 2: Initialize config server replica set
rs.initiate({
  _id: "configReplSet",
  configsvr: true,
  members: [
    { _id: 0, host: "cfg1:27019" },
    { _id: 1, host: "cfg2:27019" },
    { _id: 2, host: "cfg3:27019" }
  ]
})

// Step 3: Start mongos
mongos --configdb configReplSet/cfg1:27019,cfg2:27019,cfg3:27019

// Step 4: Add existing replica set as first shard
sh.addShard("rs0/host1:27017,host2:27017,host3:27017")

// Step 5: Enable sharding on database
sh.enableSharding("mydb")

// Step 6: Shard the collection
sh.shardCollection("mydb.users", { userId: 1 })
// Or hashed: sh.shardCollection("mydb.users", { userId: "hashed" })

// Step 7: Add additional shards
sh.addShard("rs1/shard2-host1:27017,shard2-host2:27017")
sh.addShard("rs2/shard3-host1:27017,shard3-host2:27017")

// Step 8: Monitor chunk migration
sh.status()
db.printShardingStatus()

// Check balancer status
sh.isBalancerRunning()

// View chunk distribution
use config
db.chunks.find({ ns: "mydb.users" }).count()
db.chunks.aggregate([
  { $group: { _id: "$shard", count: { $sum: 1 } } }
])

// Step 9: Update application connection string
// Old: mongodb://host1:27017,host2:27017/?replicaSet=rs0
// New: mongodb://mongos1:27017,mongos2:27017/

// Step 10: Verify data
db.users.countDocuments()  // Should match original count

// ROLLBACK PLAN (if needed)
// 1. Stop application writes
// 2. Remove shards (except original)
// 3. Disable sharding on database
// 4. Reconnect app to original replica set
// 5. Resume operations

// MONITORING DURING MIGRATION
db.currentOp()  // Watch for chunk migrations
db.serverStatus().sharding  // Shard statistics
mongotop 5  // Monitor collection activity
mongostat 5  // Monitor operations

7. What are chunks in MongoDB sharding and how does chunk splitting and migration work?

Difficulty: HardType: SubjectiveTopic: Sharding

Chunks are logical groupings of documents based on shard key ranges. MongoDB divides the shard key space into chunks, and each chunk contains documents whose shard key values fall within a specific range. For example, one chunk might contain all documents with user IDs from 1 to 1000, while another contains 1001 to 2000. By default, each chunk has a maximum size of 64 MB. When a chunk grows beyond this size due to inserts or updates, MongoDB automatically splits it into two smaller chunks. Chunk splitting is a metadata operation that updates the config servers; no data is moved during a split. The split point is chosen to divide the chunk into roughly equal sizes. After chunks are split, the balancer monitors the distribution of chunks across shards. If one shard has significantly more chunks than another, the balancer migrates chunks from the heavily loaded shard to less loaded shards. Chunk migration involves copying documents from the source shard to the destination shard, then updating metadata on config servers to reflect the new location. During migration, the chunk being migrated remains on the source shard and continues serving queries until migration completes. Once all documents are copied and verified, the metadata is updated atomically. This ensures that chunk migrations are transparent to applications, though they do consume resources like network bandwidth and disk I/O. The balancer can be configured to run only during specific time windows to avoid impacting production workloads. You can also manually split chunks or move them if needed for special circumstances. However, automatic chunk management works well for most deployments. Chunk size affects migration frequency and efficiency. Larger chunks mean fewer but longer migrations. Smaller chunks mean more frequent but faster migrations. The default 64 MB is a good balance for most workloads.

Example code

// View chunks for a collection
use config
db.chunks.find({ ns: "mydb.users" }).pretty()

// Example chunk
{
  _id: "mydb.users-userId_1000",
  ns: "mydb.users",
  min: { userId: 1000 },
  max: { userId: 2000 },
  shard: "shard0001"
}

// Chunk lifecycle:
// 1. Chunk grows beyond 64MB
// 2. MongoDB splits chunk at midpoint
//    Chunk A: userId 1000-1500
//    Chunk B: userId 1501-2000
// 3. Balancer detects imbalance
// 4. Balancer migrates Chunk B to another shard

// Manual chunk split (rarely needed)
sh.splitAt("mydb.users", { userId: 5000 })

// Change chunk size
use config
db.settings.updateOne(
  { _id: "chunksize" },
  { $set: { value: 128 } },  // 128MB chunks
  { upsert: true }
)

17. Describe the replication architecture in MongoDB. How do secondary nodes stay synchronized with the primary?

Difficulty: HardType: SubjectiveTopic: Replication

MongoDB's replication architecture centers around the primary node, which is the only node accepting write operations. When a write occurs, the primary records it in the oplog, a special capped collection in the local database. The oplog stores operations in the order they are executed. Secondary nodes continuously query the primary's oplog for new entries. When new operations appear, secondaries copy these oplog entries and apply them to their own data files in the same order. This process is called replication. The operations in the oplog are idempotent, meaning they can be applied multiple times safely without changing the result. Secondaries maintain a cursor on the primary's oplog, tracking the timestamp of the last operation they applied. They fetch operations with timestamps greater than their last applied timestamp. This allows secondaries to catch up if they fall behind due to network issues or heavy load. Sometimes a secondary can replicate from another secondary instead of the primary, a process called chained replication. This reduces load on the primary and is enabled by default. However, data always originates from the primary through the oplog. If a secondary falls too far behind and the operations it needs have been overwritten in the oplog, it must perform an initial sync, copying all data from another member. This is why oplog sizing is important for production deployments.

Example code

// Replication flow:
// 1. Write operation on primary
db.users.insertOne({ name: "Alice" })  // On primary

// 2. Primary writes to oplog
// local.oplog.rs: { ts: Timestamp(...), op: "i", ns: "db.users", o: {...} }

// 3. Secondaries query oplog
// Secondary runs: db.oplog.rs.find({ ts: { $gt: lastApplied } })

// 4. Secondaries apply operations
// Secondary executes same insert

// 5. Secondaries update their sync state
// Track timestamp of last applied operation

18. What is the oplog and why is its size important? How do you determine the appropriate oplog size?

Difficulty: HardType: SubjectiveTopic: Replication

The oplog, or operations log, is a special capped collection in the local database that records all write operations on the primary node. It stores operations in chronological order with timestamps. Secondary nodes replicate by reading the oplog and applying these operations to their data. Oplog size is critical because it is a capped collection with a fixed maximum size. Once full, the oldest entries are overwritten to make room for new operations. If a secondary falls too far behind and the operations it needs have been overwritten, it cannot catch up through normal replication and must perform a full initial sync. Determining the right oplog size depends on your write volume and how long secondaries might be offline. The oplog should be large enough to hold at least 24 to 48 hours of operations, giving you time to address issues before a secondary falls too far behind. For deployments with high write rates or where maintenance might require nodes to be offline for extended periods, you need a larger oplog. You can calculate oplog size based on your write operations per hour. Monitor your oplog window, which is the time span of operations stored in the oplog. If the window is too short relative to your maintenance windows or replication lag, increase the oplog size. MongoDB allows resizing the oplog without downtime in replica sets.

Example code

// Check current oplog size and window
use local
db.oplog.rs.stats(1024*1024)  // Size in MB

// Check oplog time window
var first = db.oplog.rs.find().sort({$natural:1}).limit(1).next()
var last = db.oplog.rs.find().sort({$natural:-1}).limit(1).next()
var window = (last.ts.getTime() - first.ts.getTime()) / 1000 / 3600
print("Oplog window: " + window + " hours")

// Resize oplog (requires replSetResizeOplog command)
db.adminCommand({
  replSetResizeOplog: 1,
  size: 16000  // Size in MB
})

20. Explain the concept of sharding in MongoDB and when you should implement it.

Difficulty: MediumType: SubjectiveTopic: Sharding

Sharding is MongoDB's method for horizontal scaling by distributing data across multiple servers called shards. Each shard is a separate database that holds a portion of the data, and together all shards form the complete dataset. This allows MongoDB to handle datasets and workloads that exceed what a single server can support. In a sharded cluster, data is partitioned based on a shard key, which is a field or fields that exist in every document. MongoDB divides the shard key values into chunks, and each chunk is assigned to a specific shard. As data grows, MongoDB automatically splits chunks and migrates them across shards to maintain balance. You should implement sharding when your dataset exceeds the storage capacity of a single server, typically when approaching several hundred gigabytes or terabytes. Sharding is also appropriate when your read or write throughput exceeds what a single server or replica set can handle, even with adequate hardware. However, sharding adds complexity to your deployment. You need config servers to store cluster metadata, mongos routers to direct queries, and multiple shard replica sets. Only implement sharding when you have exhausted other optimization options like indexing, vertical scaling, and replica set read distribution. Before sharding, ensure your application is ready. Choose your shard key carefully because it cannot be changed after sharding without recreating the collection. A good shard key provides high cardinality, even distribution, and supports your most common query patterns.

Example code

// When to shard:
// 1. Data size > single server storage (500GB-1TB+)
// 2. Working set > available RAM
// 3. Write throughput > single server capacity
// 4. Need to distribute data geographically

// Sharded cluster components:
// Config Servers: store metadata (replica set)
// Mongos Routers: query routing (multiple instances)
// Shards: store data (each is replica set)

// Basic sharding setup
sh.enableSharding("myDatabase")
sh.shardCollection("myDatabase.users", { userId: 1 })

23. What are the different backup and recovery strategies for MongoDB? Compare their advantages and disadvantages.

Difficulty: HardType: SubjectiveTopic: Backup

MongoDB offers several backup and recovery strategies, each with different trade-offs between consistency, performance impact, and ease of use. Choosing the right strategy depends on your recovery time objectives, data size, and operational requirements. First, mongodump and mongorestore are utility tools that create logical backups by reading documents and writing them to BSON files. Advantages include simplicity, platform independence, and ability to backup specific databases or collections. Disadvantages are that they are slow for large datasets, do not capture a point-in-time snapshot by default, and require significant I/O resources. Second, file system snapshots create binary copies of data files at the storage layer. Cloud providers and storage systems offer snapshot features that create consistent copies almost instantly. Advantages include speed, minimal performance impact, and point-in-time consistency. Disadvantages are dependency on specific storage systems and typically requiring the entire data directory. Third, MongoDB Cloud Manager and Ops Manager provide continuous backup with point-in-time recovery. They take periodic snapshots and capture oplog entries between snapshots, allowing you to restore to any point in time. Advantages include automated scheduling, point-in-time recovery, and minimal manual intervention. Disadvantages are cost for cloud services and complexity for on-premises Ops Manager. Fourth, delayed replica set members can serve as a live backup. Configure a secondary with a replication delay of several hours. If data corruption or accidental deletion occurs, you can recover from the delayed member before it replicates the problem. Advantages include continuous availability and simple recovery. Disadvantages are resource overhead and limited recovery window. Best practices include testing your backup and recovery procedures regularly, storing backups in a different location or region, encrypting sensitive backups, and documenting recovery procedures. Combine multiple strategies for defense in depth.

Example code

// Method 1: mongodump and mongorestore
// Backup entire database
mongodump --host=localhost --port=27017 --db=mydb --out=/backup/

// Restore from backup
mongorestore --host=localhost --port=27017 --db=mydb /backup/mydb/

// Method 2: File system snapshot (example with LVM)
lvcreate --size 10G --snapshot --name mongodb-snap /dev/vg0/mongodb
tar czf /backup/mongodb-snap.tar.gz /mnt/mongodb-snap
lvremove /dev/vg0/mongodb-snap

// Method 3: Delayed replica set member
// Configure secondary with 4-hour delay
var cfg = rs.conf()
cfg.members[2].priority = 0
cfg.members[2].hidden = true
cfg.members[2].slaveDelay = 14400  // 4 hours in seconds
rs.reconfig(cfg)

// Recovery from delayed member:
// 1. Stop delayed secondary
// 2. Copy its data files
// 3. Restore primary from these files

// Method 4: Continuous backup (conceptual)
// MongoDB Atlas automated backups:
// - Snapshots every 6-24 hours
// - Oplog between snapshots
// - Point-in-time restore to any second

37. What are the best practices for optimizing aggregation pipeline performance?

Difficulty: HardType: SubjectiveTopic: Aggregation

First, place dollar match stages as early as possible to filter documents before expensive operations. This reduces the data volume flowing through the pipeline. Use indexes for dollar match and dollar sort stages by ensuring indexed fields are used in these operations. Second, limit the data processed by using dollar project or dollar addFields to remove unnecessary fields early in the pipeline. Smaller documents flow faster through stages. Avoid using dollar lookup when possible, as joins are expensive. Consider embedding data instead of referencing. Third, use dollar limit immediately after dollar sort to prevent sorting the entire result set. MongoDB can optimize this combination to use a top-K sort algorithm, which is much faster than sorting everything then limiting. Fourth, use allowDiskUse option for large aggregations that exceed the memory limit of 100 MB. This allows MongoDB to write temporary files to disk, though it is slower than in-memory processing. Fifth, analyze your pipeline with explain method to see which stages are slow and whether indexes are being used. Sixth, for very large aggregations, consider using dollar merge or dollar out to write results to a collection, then query that collection. This is useful for reports that do not need real-time data.

Example code

// Optimized pipeline
db.orders.aggregate([
  // 1. Filter early with indexed field
  { $match: { status: "completed", date: { $gte: ISODate("2024-01-01") } } },
  
  // 2. Project only needed fields
  { $project: { customerId: 1, amount: 1, _id: 0 } },
  
  // 3. Group and calculate
  { $group: { _id: "$customerId", total: { $sum: "$amount" } } },
  
  // 4. Sort with limit (uses top-K sort)
  { $sort: { total: -1 } },
  { $limit: 100 }
], {
  allowDiskUse: true  // For large datasets
})

// Create index to support pipeline
db.orders.createIndex({ status: 1, date: 1 })

40. What are read concerns in MongoDB and how do they ensure data consistency?

Difficulty: MediumType: SubjectiveTopic: Read Write

Read concern controls the consistency and isolation properties of data read from MongoDB. It determines what data is visible to a read operation, especially in replica sets where data may not be immediately consistent across all members. Read concern local returns the most recent data available on the queried node, without guarantees that the data has been replicated. This is the default and provides the fastest reads but may return data that could be rolled back if the primary fails before replication. Read concern majority returns data that has been acknowledged by the majority of replica set members. This ensures you never read data that could be rolled back during failover. It provides strong consistency guarantees but may return slightly older data if the most recent writes have not yet replicated to the majority. Read concern linearizable provides read-your-writes consistency for single-document reads. It guarantees that read operations return data that reflects all successful writes that completed before the read started. This is useful for scenarios requiring strict consistency but has performance implications. Read concern snapshot provides point-in-time consistency for multi-document reads within transactions. All reads in the transaction see a consistent snapshot of data as it existed at the transaction start time. Choose read concern based on your consistency requirements. Use majority for critical reads where data accuracy is essential. Use local for better performance when eventual consistency is acceptable.

Example code

// Read concern 'local' - fastest, may return rollback data
db.inventory.find({ qty: { $gt: 0 } })
  .readConcern("local")

// Read concern 'majority' - durable reads, slower
db.inventory.find({ qty: { $gt: 0 } })
  .readConcern("majority")

// Read concern 'linearizable' - strongest consistency
db.inventory.findOne({ _id: 1 })
  .readConcern("linearizable")

// In transactions with snapshot isolation
const session = client.startSession()
session.startTransaction({
  readConcern: { level: "snapshot" },
  writeConcern: { w: "majority" }
})

41. Walk through what happens during a replica set failover when the primary node fails.

Difficulty: HardType: SubjectiveTopic: Replication

When the primary node fails, a coordinated failover process begins automatically. First, the secondary nodes detect that the primary is unreachable through the absence of heartbeat messages. Replica set members send heartbeat pings every two seconds, and if a member does not respond within 10 seconds, it is marked as unreachable. Second, once secondaries confirm the primary is down, they initiate an election. Any secondary can call for an election if it detects the primary is unavailable. The election process involves members voting for which secondary should become the new primary. Third, during the election, members evaluate candidates based on priority settings, data recency, and availability. Members with outdated data or lower priority will not receive votes. The election must reach a majority consensus, so in a three-member replica set, at least two members must vote for the same candidate. Fourth, once a candidate receives votes from the majority of members, it transitions to the primary role and begins accepting write operations. The entire election process typically completes in a few seconds, though it can take up to 30 seconds in some scenarios. Fifth, applications using MongoDB replica set connection strings automatically discover the new primary through the connection driver. The driver maintains a list of replica set members and can redirect operations to the new primary without manual intervention. There may be a brief period where write operations fail during the election, so applications should implement retry logic. Finally, when the failed original primary recovers and rejoins the replica set, it becomes a secondary and syncs data from the new primary.

Example code

// Timeline of failover:
// Time 0: Primary node crashes
// Time 2-10s: Secondaries detect primary unreachable (heartbeat timeout)
// Time 10s: Secondary initiates election
// Time 10-15s: Election process, members vote
// Time 15s: New primary elected, begins accepting writes
// Time 16s: Applications reconnect to new primary

// Application connection with automatic failover
const client = new MongoClient(
  'mongodb://host1:27017,host2:27017,host3:27017/?replicaSet=myRS',
  {
    retryWrites: true,  // Automatic retry on failover
    w: 'majority'        // Wait for replication
  }
)

// After failover completes
// Old primary (when recovered): joins as secondary
// New primary: handles all writes
// Other secondary: continues replicating

43. What factors should you consider when choosing a shard key? Explain the consequences of a poor shard key choice.

Difficulty: HardType: SubjectiveTopic: Shard Key

Choosing a shard key is one of the most critical decisions in sharding because it cannot be changed after sharding without rebuilding the collection. A good shard key must satisfy three main criteria: high cardinality, even distribution, and query pattern alignment. High cardinality means the shard key has many distinct values. This allows MongoDB to distribute data across many chunks and shards. Low cardinality keys, like a status field with only three values, can only create three chunks maximum, preventing effective distribution across many shards. Even distribution means queries and inserts are spread across all shards, avoiding hotspots. Monotonically increasing keys like timestamps or auto-incrementing IDs are poor choices because all new writes go to the highest chunk on one shard. This creates a write hotspot that defeats the purpose of sharding. Query pattern alignment means your most common queries should include the shard key. When queries include the shard key, mongos can route them directly to specific shards. Without the shard key in queries, mongos must broadcast to all shards, which is inefficient and slow. Poor shard key choices lead to several problems. Uneven distribution causes some shards to fill up while others remain empty, wasting resources and limiting scalability. Hotspots concentrate all activity on one shard, creating bottlenecks. Scatter-gather queries that hit all shards are slow and resource-intensive. A common strategy is using a compound shard key that combines a field with good distribution, like user ID, with a time-based field for efficient time-range queries. Another approach is using hashed shard keys for monotonically increasing values to ensure even distribution.

Example code

// Good shard key: compound with high cardinality
sh.shardCollection("db.orders", { userId: 1, orderDate: 1 })
// Pros: high cardinality, supports user queries, time-based queries
// Query: db.orders.find({ userId: 123, orderDate: {...} })
// Routes to specific shard

// Poor shard key: low cardinality
sh.shardCollection("db.orders", { status: 1 })
// Cons: only 3-4 values (pending, completed, cancelled)
// Cannot distribute beyond 3-4 chunks

// Poor shard key: monotonically increasing
sh.shardCollection("db.orders", { _id: 1 })
// Cons: all new writes to one shard (hotspot)
// Better: { _id: "hashed" }

// Queries without shard key (slow)
db.orders.find({ productId: 456 })
// Mongos broadcasts to all shards

44. Explain the difference between horizontal and vertical scaling. Why does MongoDB prefer horizontal scaling?

Difficulty: MediumType: SubjectiveTopic: Scalability

Vertical scaling means adding more resources to a single server, such as upgrading CPU, adding more RAM, or using faster storage. It is the simpler approach because your architecture remains unchanged; you just use more powerful hardware. However, vertical scaling has hard limits. There is a maximum amount of RAM, CPU, and storage you can add to a single machine, and costs increase exponentially at the high end. Horizontal scaling means adding more servers to distribute the load across multiple machines. Instead of one powerful server, you use many commodity servers working together. MongoDB implements horizontal scaling through sharding, where data is partitioned across multiple shards. MongoDB prefers horizontal scaling for several reasons. First, it has virtually unlimited capacity. You can add shards indefinitely as your data and workload grow. There is no practical upper limit like there is with vertical scaling. Second, it is more cost-effective. Adding commodity servers is cheaper than buying enterprise-grade high-end hardware. Third, horizontal scaling provides better fault tolerance. With data distributed across multiple servers, the failure of one shard does not take down the entire system. When combined with replica sets on each shard, you have both high availability and horizontal scalability. Fourth, it enables geographic distribution. You can place shards in different data centers or regions to reduce latency for users in different locations. However, horizontal scaling adds complexity. You need to manage multiple servers, choose good shard keys, and handle distributed queries. Vertical scaling remains viable for smaller deployments or when your data fits on a powerful single server. Many deployments use both strategies: vertical scaling for individual servers and horizontal scaling across multiple shards.

Example code

// Vertical scaling (single server)
// Year 1: 16GB RAM, 4 cores, 500GB storage
// Year 2: 64GB RAM, 16 cores, 2TB storage
// Year 3: 256GB RAM, 32 cores, 8TB storage
// Eventually: Cannot scale further, very expensive

// Horizontal scaling (sharding)
// Year 1: 3 shards, 16GB RAM each
// Year 2: 6 shards, 16GB RAM each
// Year 3: 12 shards, 16GB RAM each
// Can continue adding shards indefinitely

// Sharding setup for horizontal scaling
sh.addShard("shard1/host1:27017")
sh.addShard("shard2/host2:27017")
sh.addShard("shard3/host3:27017")
// Add more shards as needed

45. What is zone sharding in MongoDB and when would you use it?

Difficulty: HardType: SubjectiveTopic: Sharding

Zone sharding, also called tag-aware sharding, allows you to control which shards store specific ranges of data based on shard key values. You create zones, associate shards with zones, and define shard key ranges for each zone. The balancer then ensures chunks falling within zone ranges are migrated to shards associated with those zones. Zone sharding is useful for several scenarios. First, geographic data distribution where you want to keep data close to users. For example, you can create US zone and EU zone, assign shards in US data centers to US zone and shards in EU data centers to EU zone, then define ranges like user IDs starting with 1 for US and 2 for EU. Second, data tiering based on access patterns. You might have hot data that is frequently accessed and cold data that is rarely accessed. Create hot zone on fast SSD-backed shards and cold zone on cheaper HDD-backed shards, then assign recent data to hot zone and old data to cold zone based on date ranges. Third, multi-tenancy where you want to isolate different customers on different hardware. Create zones for different customer tiers, like premium zone on powerful hardware and standard zone on regular hardware, then assign customers to appropriate zones. To implement zone sharding, first add shards to zones using sh.addShardToZone. Then define the ranges of shard key values for each zone using sh.updateZoneKeyRange. The balancer automatically migrates chunks to respect zone boundaries. This happens gradually and transparently. Zone sharding adds complexity because you must manage zone definitions and shard assignments. Use it only when you have clear requirements for data placement. For most applications, automatic chunk distribution without zones is sufficient.

Example code

// Geographic zone sharding

// 1. Add shards to zones
sh.addShardToZone("shard-us-west", "US")
sh.addShardToZone("shard-us-east", "US")
sh.addShardToZone("shard-eu-west", "EU")

// 2. Define shard key ranges for zones
sh.updateZoneKeyRange(
  "mydb.users",
  { userId: 1000000, country: "US" },
  { userId: 1999999, country: "US" },
  "US"
)

sh.updateZoneKeyRange(
  "mydb.users",
  { userId: 2000000, country: "EU" },
  { userId: 2999999, country: "EU" },
  "EU"
)

// 3. Balancer migrates chunks to appropriate shards
// US users' data stays on US shards
// EU users' data stays on EU shards

// Result: reduced latency for users
// US user queries hit US shards (low latency)
// EU user queries hit EU shards (low latency)

46. How do you monitor and troubleshoot MongoDB performance issues in production?

Difficulty: HardType: SubjectiveTopic: Monitoring

Monitoring and troubleshooting MongoDB performance requires a systematic approach using built-in tools, metrics analysis, and query optimization techniques. Proactive monitoring helps identify issues before they impact users. First, use MongoDB's built-in monitoring tools. The db.serverStatus command provides comprehensive metrics including connections, memory usage, operations, network traffic, and storage statistics. The db.currentOp command shows currently running operations, helping identify long-running queries. The mongostat utility displays real-time statistics on operations, connections, and resource usage. Second, enable database profiling to capture slow queries. The profiler records queries exceeding a specified threshold to the system.profile collection. Set profiling level 1 to log slow queries or level 2 to log all queries. Analyze profiled queries to identify optimization opportunities. Use explain method on slow queries to understand execution plans and index usage. Third, monitor key performance metrics. Watch for high query execution times, low cache hit ratios indicating insufficient memory, high page faults showing working set exceeds RAM, connection saturation, replication lag in replica sets, and uneven shard distribution in sharded clusters. Set up alerts for abnormal values. Fourth, use monitoring platforms like MongoDB Cloud Manager, Ops Manager, or third-party tools like Prometheus and Grafana. These provide historical trending, alerting, and dashboards. They help identify patterns and correlate metrics across multiple servers. Fifth, when troubleshooting specific issues, follow a structured approach. For slow queries, use explain to check if indexes are used, verify index selectivity, and ensure query patterns match shard keys in sharded clusters. For memory issues, check working set size versus available RAM and consider adding memory or sharding. For write performance, verify write concern settings, check for lock contention, and ensure indexes are not over-indexed causing write overhead. Regularly review and optimize indexes, remove unused indexes, monitor index size and fragmentation, and rebuild indexes if needed. Test changes in staging environments before applying to production.

Example code

// 1. Check current operations
db.currentOp({
  "active": true,
  "secs_running": { "$gt": 5 }  // Running > 5 seconds
})

// Kill long-running operation
db.killOp(12345)

// 2. Enable profiling for slow queries (> 100ms)
db.setProfilingLevel(1, { slowms: 100 })

// Analyze slow queries
db.system.profile.find().sort({ ts: -1 }).limit(10)

// 3. Get server statistics
db.serverStatus()

// Key metrics to monitor:
// - connections.current (connection count)
// - opcounters (operations per second)
// - mem.resident (RAM usage)
// - wiredTiger.cache (cache statistics)
// - network.bytesIn/bytesOut
// - repl.lag (replication lag)

// 4. Check database statistics
db.stats()

// 5. Analyze query performance
db.orders.find({ customerId: 123 }).explain("executionStats")

// Look for:
// - executionTimeMillis (total time)
// - totalDocsExamined vs totalDocsReturned
// - stage: "IXSCAN" (using index) vs "COLLSCAN" (full scan)

// 6. Check index usage statistics
db.orders.aggregate([{ $indexStats: {} }])

// 7. Monitor with mongostat (external command)
mongstat --host localhost:27017 5
// Shows operations, memory, connections every 5 seconds

47. What are the key features and advantages of MongoDB Atlas compared to self-hosted MongoDB?

Difficulty: MediumType: SubjectiveTopic: Atlas

MongoDB Atlas is a fully managed cloud database service that eliminates the operational overhead of running MongoDB infrastructure. While self-hosted MongoDB provides full control, Atlas offers significant advantages in ease of use, reliability, and advanced features. First, automated deployment and scaling. Atlas handles cluster provisioning, configuration, and scaling across AWS, Azure, and Google Cloud. You can scale vertically by changing instance sizes or horizontally by adding shards with a few clicks. Auto-scaling can adjust resources based on workload patterns. Self-hosted MongoDB requires manual server provisioning, configuration management, and scaling procedures. Second, continuous backups with point-in-time recovery. Atlas automatically takes snapshots and captures oplog entries, allowing restore to any point in time. Cloud backups are stored in different regions for disaster recovery. Self-hosted deployments require implementing and maintaining backup solutions manually. Third, built-in monitoring and alerting. Atlas provides real-time performance metrics, query profiling, and customizable alerts for issues like high CPU, replication lag, or connection spikes. The performance advisor suggests index improvements. Self-hosted monitoring requires deploying and configuring separate monitoring tools. Fourth, global clusters for multi-region deployments. Atlas supports geo-distributed clusters with data locality controls, allowing you to store data close to users in different regions while maintaining a single database view. This reduces latency and supports compliance requirements. Implementing multi-region setups with self-hosted MongoDB is complex. Fifth, integrated security features including encryption at rest and in transit by default, network isolation through VPC peering, IP whitelisting, database authentication with various mechanisms, and audit logging. Self-hosted deployments must configure each security layer manually. Sixth, automated patching and updates. Atlas handles MongoDB version upgrades, security patches, and driver updates with minimal downtime. Self-hosted deployments require planning and executing maintenance windows. Seventh, serverless instances for development and variable workloads. Atlas Serverless automatically scales compute and storage based on usage and charges only for resources consumed. This is ideal for applications with unpredictable traffic or development environments. The main disadvantages of Atlas are cost, which can be higher than self-hosted for stable workloads, less control over infrastructure and configuration details, and potential vendor lock-in. Choose Atlas when you want to focus on application development rather than database operations, need enterprise features without complexity, require multi-region deployment, or want predictable operational costs.

Example code

// Atlas Connection String
const uri = "mongodb+srv://user:pass@cluster0.mongodb.net/mydb?retryWrites=true&w=majority"

// Atlas Exclusive Features:

// 1. Global Clusters (multi-region)
// - Data in US, Europe, Asia
// - Zone sharding by region
// - Low-latency worldwide access

// 2. Atlas Search (full-text search)
db.products.aggregate([
  {
    $search: {
      index: "default",
      text: {
        query: "laptop gaming",
        path: ["title", "description"]
      }
    }
  }
])

// 3. Atlas Data Lake (query S3 data)
// - Analyze data in cloud storage
// - Federated queries across MongoDB and S3

// 4. Automated Backup Schedule
// - Snapshots: every 6-24 hours
// - Oplog: continuous
// - Retention: 7 days to indefinite
// - Point-in-time restore to any second

// 5. Performance Advisor
// - Suggests missing indexes
// - Identifies slow queries
// - Recommends schema improvements

// 6. Atlas Triggers (serverless functions)
// - React to database changes
// - Scheduled functions
// - Event-driven architecture

// 7. Charts (data visualization)
// - Build dashboards
// - Embedded analytics
// - No coding required

48. Given an employees collection with nested salary history and skills array, write queries to find employees with specific criteria and calculate aggregations.

Difficulty: HardType: SubjectiveTopic: Querying

Working with complex document structures in MongoDB requires understanding nested field access, array queries, and aggregation pipelines. Let's explore practical query scenarios using an employees collection with embedded documents and arrays. For querying nested fields, use dot notation to access fields within embedded documents. For example, to find employees in a specific city, query address.city. MongoDB treats embedded documents as regular fields once you use dot notation. For array queries, MongoDB provides specialized operators. To find employees with a specific skill, use the array field directly and MongoDB matches if any element equals the value. For complex array conditions, use dollar elemMatch to ensure all conditions apply to the same array element. For aggregation scenarios, use the aggregation pipeline to perform calculations across documents. The dollar group stage groups documents by fields and calculates aggregates using accumulator operators like dollar sum, dollar avg, dollar max, and dollar min. For sorting by nested or computed fields, use dollar addFields to create temporary fields, then dollar sort on those fields. This is useful when sorting by array length or computed values. For filtering arrays and projections, use dollar filter in aggregation pipelines to include only specific array elements in results. This is more powerful than projection alone because you can apply complex conditions. For combining multiple conditions, use logical operators like dollar and, dollar or, and dollar not to build complex queries. Array operators like dollar all ensure arrays contain all specified values, while dollar in matches if the field equals any value in an array. These techniques combine to enable sophisticated queries on complex document structures while maintaining query performance through proper indexing on query fields.

Example code

// Sample employees collection structure
{
  _id: 1,
  name: "Alice Johnson",
  age: 32,
  department: "Engineering",
  salary: 95000,
  address: {
    street: "123 Main St",
    city: "San Francisco",
    zip: "94102"
  },
  skills: ["JavaScript", "Python", "MongoDB"],
  projects: [
    { name: "Project A", role: "Lead", duration: 6 },
    { name: "Project B", role: "Developer", duration: 3 }
  ]
}

// Query 1: Find employees in San Francisco with salary > 80000
db.employees.find({
  "address.city": "San Francisco",
  salary: { $gt: 80000 }
})

// Query 2: Find employees with both JavaScript AND Python skills
db.employees.find({
  skills: { $all: ["JavaScript", "Python"] }
})

// Query 3: Find employees who were Lead in any project for > 5 months
db.employees.find({
  projects: {
    $elemMatch: {
      role: "Lead",
      duration: { $gt: 5 }
    }
  }
})

// Query 4: Count employees by department
db.employees.aggregate([
  {
    $group: {
      _id: "$department",
      count: { $sum: 1 },
      avgSalary: { $avg: "$salary" }
    }
  },
  { $sort: { avgSalary: -1 } }
])

// Query 5: Find top 3 highest paid employees by department
db.employees.aggregate([
  { $sort: { department: 1, salary: -1 } },
  {
    $group: {
      _id: "$department",
      topEmployees: {
        $push: {
          name: "$name",
          salary: "$salary"
        }
      }
    }
  },
  {
    $project: {
      department: "$_id",
      topEmployees: { $slice: ["$topEmployees", 3] },
      _id: 0
    }
  }
])

// Query 6: Employees with more than 3 skills, sorted by skill count
db.employees.aggregate([
  {
    $addFields: {
      skillCount: { $size: "$skills" }
    }
  },
  { $match: { skillCount: { $gt: 3 } } },
  { $sort: { skillCount: -1 } },
  {
    $project: {
      name: 1,
      skillCount: 1,
      skills: 1
    }
  }
])

// Query 7: Employees in SF or NYC with specific skills
db.employees.find({
  $or: [
    { "address.city": "San Francisco" },
    { "address.city": "New York" }
  ],
  skills: { $in: ["MongoDB", "PostgreSQL"] }
})

51. Explain multi-document transactions in MongoDB. How do they ensure ACID properties and what are their limitations?

Difficulty: HardType: SubjectiveTopic: Transactions

Multi-document transactions in MongoDB allow you to execute multiple operations across multiple documents and collections atomically, ensuring ACID properties: Atomicity, Consistency, Isolation, and Durability. Either all operations in a transaction succeed and are committed, or all fail and are rolled back. Atomicity means all operations in the transaction complete successfully or none do. If any operation fails, all previous operations are rolled back. Consistency ensures the database moves from one valid state to another. Isolation means concurrent transactions do not interfere with each other. Durability guarantees committed transactions survive system failures. To use transactions, you start a session, begin a transaction, perform operations passing the session to each operation, and then commit or abort the transaction. MongoDB uses write-ahead logging and the oplog to implement transaction guarantees. During a transaction, changes are not visible to other operations until commit. Transactions have important limitations. First, they are only available on replica sets and sharded clusters, not standalone instances. Second, they have a 60-second default timeout and are subject to the 16 MB oplog entry size limit. Third, transactions that affect multiple shards have additional overhead. Fourth, transactions should be kept short because they hold locks on documents. Long-running transactions can block other operations and affect performance. Fifth, DDL operations like creating indexes cannot be performed inside transactions. Finally, transactions add latency compared to individual operations, so use them only when atomicity across multiple documents is truly required.

Example code

// Bank transfer example - ACID transaction
const session = client.startSession()

try {
  session.startTransaction({
    readConcern: { level: 'snapshot' },
    writeConcern: { w: 'majority' }
  })
  
  // Deduct from account 1
  const result1 = await db.accounts.updateOne(
    { _id: 'account1', balance: { $gte: 100 } },
    { $inc: { balance: -100 } },
    { session }
  )
  
  if (result1.modifiedCount === 0) {
    throw new Error('Insufficient funds')
  }
  
  // Add to account 2
  await db.accounts.updateOne(
    { _id: 'account2' },
    { $inc: { balance: 100 } },
    { session }
  )
  
  // Record transaction
  await db.transfers.insertOne(
    { from: 'account1', to: 'account2', amount: 100 },
    { session }
  )
  
  // Commit - all or nothing
  await session.commitTransaction()
  
} catch (error) {
  // Rollback all changes
  await session.abortTransaction()
  throw error
} finally {
  session.endSession()
}

Google MongoDB/NoSQL Interview Questions | Preplance | Preplance

Master Interviews Anywhere, Anytime

Google MongoDB/NoSQL interview questions

Quick overview

1. Which characteristic is MOST important when choosing a shard key?

Continue your preparation

2. Explain geospatial indexes in MongoDB. What are the differences between 2d and 2dsphere indexes?

3. What are the essential best practices for deploying MongoDB in production environments?

4. What is the role of journaling in MongoDB?

5. Explain the trade-offs between embedding documents versus referencing in MongoDB. When should you use each approach?

6. What steps and considerations are involved in migrating a large production database from a single MongoDB instance to a sharded cluster with minimal downtime?

7. What are chunks in MongoDB sharding and how does chunk splitting and migration work?

8. Which operator is used to update or add a field in a MongoDB document?

9. What is the default index automatically created by MongoDB for every collection?

10. What type of index is required to perform text search in MongoDB?

11. Explain the difference between $in and $or operators in MongoDB queries.

12. What is the explain() method in MongoDB and what key metrics should you look for when analyzing query performance?

13. In the aggregation pipeline, which accumulator operator calculates the average value?

14. What does the $lookup stage do in MongoDB aggregation?

15. What is Map-Reduce in MongoDB and how does it compare to the Aggregation Framework?

16. What is the oplog in MongoDB replication?

17. Describe the replication architecture in MongoDB. How do secondary nodes stay synchronized with the primary?

18. What is the oplog and why is its size important? How do you determine the appropriate oplog size?

19. What is the role of mongos in a sharded cluster?

20. Explain the concept of sharding in MongoDB and when you should implement it.

21. Which storage engine is the default in MongoDB 3.2 and later?

22. When should you use GridFS in MongoDB?

23. What are the different backup and recovery strategies for MongoDB? Compare their advantages and disadvantages.

24. What is the advantage of using bulkWrite() over multiple individual write operations?

25. What are the key differences between MongoDB and relational databases?

26. Explain the four basic CRUD operations in MongoDB with examples.

27. When should you choose MongoDB over a relational database?

28. Which operator matches documents where an array field contains all specified elements?

29. For a compound index { age: 1, city: 1 }, which query can use this index efficiently?

30. What is a compound index and when should you use it? Explain the index prefix rule.

31. What strategies can you use to optimize slow MongoDB queries?

32. What is the recommended order for aggregation stages to optimize performance?

33. Explain what the MongoDB Aggregation Framework is and how it differs from regular find queries.

34. When does an election occur in a MongoDB replica set?

35. How would you use aggregation to find the top 5 customers by total purchase amount? Explain each stage.

36. Explain how to use $lookup to join collections in MongoDB aggregation. When should you avoid using $lookup?

37. What are the best practices for optimizing aggregation pipeline performance?

38. Which statement is TRUE about the primary node in a replica set?

39. Explain the concept of replica sets in MongoDB and how they ensure high availability.

40. What are read concerns in MongoDB and how do they ensure data consistency?

41. Walk through what happens during a replica set failover when the primary node fails.

42. What triggers chunk migration in a sharded cluster?

43. What factors should you consider when choosing a shard key? Explain the consequences of a poor shard key choice.

44. Explain the difference between horizontal and vertical scaling. Why does MongoDB prefer horizontal scaling?

45. What is zone sharding in MongoDB and when would you use it?

46. How do you monitor and troubleshoot MongoDB performance issues in production?

47. What are the key features and advantages of MongoDB Atlas compared to self-hosted MongoDB?

48. Given an employees collection with nested salary history and skills array, write queries to find employees with specific criteria and calculate aggregations.

49. Explain horizontal scalability in MongoDB and how it differs from vertical scalability.

50. What do Change Streams in MongoDB allow applications to do?

51. Explain multi-document transactions in MongoDB. How do they ensure ACID properties and what are their limitations?

52. Which MongoDB tools are used for importing and exporting data?

Master Interviews
Anywhere, Anytime