Transactions and Concurrency

1. What is a transaction in MongoDB?

A transaction groups multiple read/write operations into a single logical unit that either fully commits or fully aborts — giving you ACID guarantees (Atomicity, Consistency, Isolation, Durability) across multiple documents and even multiple collections. Multi-document transactions have been available since 4.0 on replica sets and 4.2 on sharded clusters.

const session = db.getMongo().startSession()
session.startTransaction({ readConcern: { level: "snapshot" }, writeConcern: { w: "majority" } })
try {
  const accts = session.getDatabase("bank").accounts
  accts.updateOne({ _id: "A" }, { $inc: { balance: -100 } })
  accts.updateOne({ _id: "B" }, { $inc: { balance:  100 } })
  session.commitTransaction()
} catch (e) {
  session.abortTransaction()
} finally {
  session.endSession()
}

The point interviewers want you to make: a single-document write is always atomic on its own — no transaction needed. So if you model related data by embedding it in one document, you often avoid transactions entirely. Reach for a multi-document transaction only when atomicity must span documents (e.g. transfers between accounts).

Gotchas: transactions hold locks and resources, so keep them short — there's a 60-second default time limit, and long ones risk write conflicts and aborts. Always retry on the transient TransientTransactionError. They carry real overhead, so they're a targeted tool, not the default.

↑ Back to top

Follow-up 1

How does MongoDB handle transactions?

MongoDB handles transactions using a two-phase commit protocol. In the first phase, the transaction coordinator sends a prepare message to all the participants, which are the MongoDB instances involved in the transaction. Each participant then writes the changes to a local transaction log. In the second phase, the transaction coordinator sends a commit message to all the participants, and they apply the changes from the transaction log to the database. If any participant fails during the transaction, the coordinator sends an abort message to all the participants, and they roll back the changes.

Follow-up 2

What are the benefits of using transactions in MongoDB?

Using transactions in MongoDB provides several benefits:

Atomicity: Transactions ensure that either all the operations within a transaction are successfully applied or none of them are. This helps maintain data integrity.
Consistency: Transactions provide a consistent view of the data by ensuring that the changes made by a transaction are isolated from other transactions until they are committed.
Isolation: Transactions in MongoDB are isolated from each other, meaning that the changes made by one transaction are not visible to other transactions until they are committed.
Durability: Transactions guarantee that once they are committed, the changes made by the transaction are durable and will survive any subsequent failures.
Flexibility: Transactions allow you to perform complex operations involving multiple documents and collections in a single logical unit.

Follow-up 3

Can you explain the concept of multi-document transactions in MongoDB?

Multi-document transactions in MongoDB allow you to perform operations on multiple documents and collections within a single transaction. This means that you can update multiple documents, insert new documents, and delete documents as part of a single transaction. All the changes made within a multi-document transaction are isolated from other transactions until they are committed. This ensures that the changes made by a transaction are consistent and atomic. Multi-document transactions in MongoDB are useful when you need to maintain data integrity across multiple documents or collections.

Follow-up 4

How does MongoDB ensure data consistency during transactions?

MongoDB ensures data consistency during transactions by using a two-phase commit protocol. In the first phase, the transaction coordinator sends a prepare message to all the participants, which are the MongoDB instances involved in the transaction. Each participant writes the changes to a local transaction log. This ensures that the changes made by a transaction are isolated from other transactions until they are committed. In the second phase, the transaction coordinator sends a commit message to all the participants, and they apply the changes from the transaction log to the database. If any participant fails during the transaction, the coordinator sends an abort message to all the participants, and they roll back the changes. This ensures that the changes made by a transaction are either all applied or none of them are.

2. What do you understand by concurrency in MongoDB?

Concurrency is MongoDB's ability to serve many simultaneous reads and writes correctly without clients corrupting each other's data. The WiredTiger storage engine handles this with document-level concurrency control plus MVCC (multi-version concurrency control).

How it works:

Document-level granularity: two writes to different documents proceed in parallel; only concurrent writes to the same document conflict.
MVCC: readers see a consistent snapshot of a document and aren't blocked by writers — a read never has to wait for a write to finish.
Optimistic concurrency: when two operations contend for the same document, one gets a write conflict and MongoDB transparently retries it. You rarely see this unless contention is high.
Atomicity: every single-document write is atomic, so concurrent $inc operations on a counter, for example, won't lose updates.

// Atomic read-modify-write — safe under concurrency, no lost updates
db.inventory.updateOne({ _id: 1, qty: { $gte: 1 } }, { $inc: { qty: -1 } })

What interviewers probe: the difference between document-level (modern WiredTiger) and the old global/collection locks; why you use atomic operators like $inc and findAndModify instead of read-then-write-back patterns that race; and Read Concern / Write Concern as the knobs that tune the consistency–durability trade-off across the replica set.

↑ Back to top

Follow-up 1

What is a lock in MongoDB and how does it relate to concurrency?

In MongoDB, a lock is a mechanism used to control access to data during concurrent operations. It ensures that only one operation can modify a piece of data at a time to maintain data consistency. MongoDB uses a fine-grained locking system where locks are acquired at the document level. This allows multiple operations to be performed concurrently on different documents.

Follow-up 2

How does MongoDB handle concurrent read and write operations?

MongoDB uses a multi-version concurrency control (MVCC) mechanism to handle concurrent read and write operations. MVCC allows multiple transactions to access the same data concurrently by creating multiple versions of the data. Each transaction sees a consistent snapshot of the data at the time it started.

Follow-up 3

How does MongoDB ensure data integrity during concurrent operations?

MongoDB ensures data integrity during concurrent operations by using the multi-version concurrency control (MVCC) mechanism and the fine-grained locking system. MVCC creates multiple versions of the data, allowing each transaction to see a consistent snapshot of the data at the time it started. The fine-grained locking system ensures that only one operation can modify a document at a time, preventing conflicts and maintaining data consistency.

Follow-up 4

What is the role of the WiredTiger storage engine in managing concurrency in MongoDB?

The WiredTiger storage engine is the default storage engine in MongoDB since version 3.2. It is designed to handle high concurrency workloads efficiently. WiredTiger uses a combination of techniques such as multi-version concurrency control (MVCC), document-level locking, and efficient data compression to manage concurrency in MongoDB. It allows multiple read and write operations to be performed concurrently while ensuring data integrity and high performance.

3. How does MongoDB handle isolation in transactions?

MongoDB gives transactions snapshot isolation via the WiredTiger storage engine's MVCC (multi-version concurrency control). When a transaction starts, it pins a consistent snapshot of the data as of that moment, and every read inside the transaction sees that snapshot — never the partial, uncommitted changes of other in-flight transactions.

Key mechanics:

Snapshot read concern: starting a transaction with readConcern: { level: "snapshot" } guarantees all reads come from one consistent point in time, even across multiple documents and collections.
No dirty reads: other sessions can't see a transaction's writes until it commits; on abort they vanish entirely.
Write conflicts, not blocking: if two transactions try to modify the same document, MongoDB detects the conflict and aborts one rather than letting them interleave. The application retries the aborted one (handle TransientTransactionError).

session.startTransaction({ readConcern: { level: "snapshot" }, writeConcern: { w: "majority" } })

The nuance interviewers want: MongoDB's isolation is snapshot isolation, not full serializable isolation, so it prevents dirty/non-repeatable reads but the application must still handle write conflicts via retry. Outside transactions, single-document writes remain atomic on their own.

↑ Back to top

Follow-up 1

What is the concept of 'Read Committed' in MongoDB?

In MongoDB, 'Read Committed' is a transaction isolation level that ensures that a transaction only sees data that has been committed by other transactions. This means that a transaction will not see any uncommitted changes made by other concurrent transactions. 'Read Committed' is the default isolation level in MongoDB transactions.

Follow-up 2

How does MongoDB ensure isolation during concurrent transactions?

MongoDB ensures isolation during concurrent transactions by using multi-version concurrency control (MVCC). MVCC allows multiple transactions to read and write data concurrently without interfering with each other. Each transaction operates on a consistent snapshot of the data, which represents a consistent view of the data at the start of the transaction. This ensures that each transaction sees a consistent set of data and that changes made by one transaction do not affect the results of other concurrent transactions.

Follow-up 3

What are the potential issues that can arise without proper isolation in MongoDB transactions?

Without proper isolation in MongoDB transactions, several potential issues can arise, including:

Dirty Reads: A dirty read occurs when a transaction reads data that has been modified by another transaction but not yet committed. This can lead to inconsistent or incorrect results.
Non-Repeatable Reads: A non-repeatable read occurs when a transaction reads the same data multiple times and gets different results each time due to changes made by other concurrent transactions.
Phantom Reads: A phantom read occurs when a transaction reads a set of data multiple times and gets different results each time due to changes made by other concurrent transactions, resulting in the appearance of new rows or missing rows.

Proper isolation ensures that these issues are avoided and that each transaction operates on a consistent set of data.

4. What is the role of the 'oplog' in MongoDB transactions?

One clarification first: the oplog isn't really a "transaction" mechanism — it's the engine of replication. The framing slightly conflates the two, so here's how they actually relate.

The oplog (operations log) is a special capped collection in the local database that records every write that modifies data, stored as idempotent operations (so they can be replayed safely). Secondaries continuously tail the oplog and apply those entries to stay in sync with the primary. It's also the basis for change streams.

Where transactions come in: when a multi-document transaction commits, all of its writes are written to the oplog as a single atomic unit (in 4.2+ this can span multiple oplog entries linked together, but they're applied all-or-nothing). This means a secondary either replays the entire committed transaction or none of it — preserving atomicity across the replica set. An aborted transaction never reaches the oplog at all.

// The oplog lives here; it's capped and circular
use local
db.oplog.rs.find().sort({ $natural: -1 }).limit(1)

The gotcha: because the oplog is capped (circular, fixed-size), a secondary that falls too far behind can have the entries it still needs overwritten — forcing a full resync. Sizing the oplog window for your write volume and maintenance gaps is a real operational concern.

↑ Back to top

Follow-up 1

How does the oplog contribute to data consistency in MongoDB?

The oplog plays a crucial role in ensuring data consistency in MongoDB. When a write operation is performed on the primary node of a replica set, the operation is first recorded in the oplog. The secondary nodes then replicate the oplog and apply the same write operation to their own data sets. This ensures that all nodes in the replica set have consistent data.

Follow-up 2

What happens if the oplog is full?

If the oplog becomes full, MongoDB will stop accepting write operations on the primary node until there is enough space in the oplog to accommodate new operations. This can happen if the rate of write operations exceeds the rate at which the oplog can be replicated to the secondary nodes. It is important to monitor the oplog size and adjust it accordingly to avoid this situation.

Follow-up 3

How can you configure the size of the oplog in MongoDB?

The size of the oplog can be configured during the initialization of a replica set or by modifying the configuration of an existing replica set. The oplog size is specified using the 'oplogSizeMB' parameter, which represents the maximum size of the oplog in megabytes. It is recommended to set the oplog size based on the expected write workload and the replication lag tolerance. Increasing the oplog size allows for a longer history of write operations, but it also increases the storage requirements.

5. Can you explain the concept of 'Write Concern' in MongoDB transactions?

Write Concern specifies the level of acknowledgment a write must receive before MongoDB reports it as successful — it's the knob that trades durability against latency in a replica set.

The components:

w — how many members must acknowledge the write. w: 1 = just the primary; w: "majority" = a majority of voting members (the durable default in modern MongoDB, and required inside transactions).
j — whether the write must be flushed to the on-disk journal before acknowledgment (j: true survives a crash).
wtimeout — a millisecond cap so a write doesn't block forever waiting for unavailable members.

db.orders.insertOne(
  { item: "widget", qty: 5 },
  { writeConcern: { w: "majority", j: true, wtimeout: 5000 } }
)

What interviewers want you to nail:

w: 1 is fast but not failover-safe — if the primary dies before replicating, an election can roll that write back. w: "majority" guarantees the write survives failover.
It's a deliberate trade-off: higher w/j = stronger durability but more latency.
Write Concern is about durability on write; its read-side counterpart is Read Concern (local, majority, snapshot, linearizable), which controls how up-to-date and consistent the data you read is. Interviewers often ask about both together.

↑ Back to top

Follow-up 1

What are the different levels of write concern in MongoDB?

The different levels of write concern in MongoDB are:

Unacknowledged: The server does not acknowledge the receipt of the write operation. This is the fastest write concern but provides no guarantee of write durability or consistency.
Acknowledged: The server acknowledges the receipt of the write operation, but not necessarily that it has been written to disk. This is the default write concern in MongoDB.
Journaled: The server acknowledges the receipt of the write operation and commits it to the journal, ensuring durability even in the event of a server crash.
Majority: The server acknowledges the receipt of the write operation and waits for a majority of replica set members to acknowledge the write before considering it successful. This provides increased durability and consistency.
Custom: Custom write concerns can be defined to meet specific requirements.

Follow-up 2

How does write concern affect the performance and reliability of MongoDB transactions?

The write concern level chosen for MongoDB transactions can have an impact on both performance and reliability.

Performance: Higher levels of write concern, such as 'majority' or 'journaled', can introduce additional latency as the server waits for acknowledgments from multiple replica set members or commits the write to the journal. This can impact the overall performance of write operations.
Reliability: Higher levels of write concern provide increased durability and consistency guarantees. For example, 'journaled' write concern ensures that the write operation is committed to the journal, even in the event of a server crash. This improves the reliability of data.

It is important to choose an appropriate write concern level based on the specific requirements of the application, balancing performance and reliability considerations.

Follow-up 3

How can you configure the write concern in MongoDB?

The write concern in MongoDB can be configured at various levels:

Global level: The default write concern for all write operations can be set using the w option in the MongoDB configuration file or by using the --writeConcern option when starting the MongoDB server.
Database level: The write concern for a specific database can be set using the db.getMongo().setWriteConcern() method in the MongoDB shell.
Collection level: The write concern for a specific collection can be set using the db.collection.setWriteConcern() method in the MongoDB shell.
Operation level: The write concern for a specific write operation can be specified as an option in the write operation itself, such as db.collection.insertOne(document, { writeConcern: { w: 'majority' } }).

By configuring the write concern at different levels, you can customize the durability and consistency guarantees for MongoDB transactions.