Update operations modify the fields and values of a document while keeping other fields and values unchanged. Replace operations substitute all fields and values in an existing document with specified fields and values while keeping the _id field value unchanged.
updateOne()
updateMany()
replaceOne()
$set: replaces the value of a field with a specified one
$inc: increments or decrements field values
$rename: renames fields
$unset: removes fields
$mul: multiplies a field value by a specified number
We have a collection of user profiles, each document has a 'loginCount' field. How would you increment that field each time the user logs in?
A bug requires you to rename the field 'addr' to 'address' in all existing documents. Which MongoDB update operator would you use and how?
If you need to add a new field 'isActive' with default true to a single document identified by its _id, how would you write that update?
Our service needs to add a new tag to an array field 'tags' for all products that match a certain category, but we must avoid duplicate tags. How would you construct the update?
During a rollout we discovered that some orders are missing a 'status' field. We want to set it to 'pending' for those documents, but only if the field doesn't exist. How would you implement this in MongoDB, and what considerations are there for concurrency?
We attempted an update with upsert:true but observed that duplicate documents were created under high load. Walk me through why that might happen and how you'd fix it.
Our analytics pipeline needs to migrate a large collection from storing timestamps as strings to ISODate objects. Describe how you would perform this migration with minimal impact on read/write latency.
We have a sharded cluster and need to run a bulk update that modifies a field used as a shard key. What are the risks and how would you approach this operation?
Explain how you would use MongoDB's change streams to audit document modifications in a high‑throughput microservice, and what performance trade‑offs you would consider.
Our organization is moving from a monolithic MongoDB deployment to a multi‑region, polyglot persistence architecture. How would you design a strategy for evolving document schemas across services while ensuring backward compatibility?
We need to deprecate a field used by several legacy services without causing downtime. Outline a phased migration plan, including how you’d handle versioning and data validation.
Discuss the pros and cons of using server‑side scripts (e.g., $where) versus application‑level logic for complex document modifications at scale.