Bird
Raised Fist0
MongoDBquery~5 mins

Transactions vs atomic document writes in MongoDB - Performance Comparison

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Time Complexity: Transactions vs atomic document writes
O(n)
Understanding Time Complexity

When working with MongoDB, it's important to know how operations take time as data grows.

We want to see how transactions compare to atomic document writes in terms of time cost.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

// Atomic document write
db.collection.updateOne(
  { _id: 1 },
  { $set: { field: 'value' } }
);

// Multi-document transaction
const session = client.startSession();
session.startTransaction();
try {
  db.collection1.updateOne({ _id: 1 }, { $set: { field: 'value' } }, { session });
  db.collection2.updateOne({ _id: 2 }, { $set: { field: 'value' } }, { session });
  await session.commitTransaction();
} finally {
  session.endSession();
}

This code shows a simple atomic update on one document versus a transaction updating multiple documents.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

  • Primary operation: Single document update for atomic write; multiple document updates inside a transaction.
  • How many times: Atomic write updates one document once; transaction updates multiple documents sequentially.
How Execution Grows With Input

As the number of documents to update grows, atomic writes stay simple but transactions handle more steps.

Input Size (n)Approx. Operations
1 document1 update operation
10 documents10 update operations inside transaction
100 documents100 update operations inside transaction

Pattern observation: Atomic writes handle one document quickly; transactions grow linearly with documents updated.

Final Time Complexity

Time Complexity: O(n)

This means the time grows roughly in direct proportion to the number of documents updated in the transaction.

Common Mistake

[X] Wrong: "Transactions are always slower than atomic writes regardless of how many documents are involved."

[OK] Correct: Transactions add overhead but if you update many documents, doing them separately can be slower or inconsistent. The time depends on how many documents are updated, not just the use of transactions.

Interview Connect

Understanding how transactions scale helps you explain trade-offs in real projects where data consistency matters.

Self-Check

"What if we used bulk writes instead of transactions? How would the time complexity change?"

Practice

(1/5)
1. Which statement best describes atomic document writes in MongoDB?
easy
A. They require manual rollback on failure.
B. They group multiple documents to update together.
C. They allow partial updates on multiple documents.
D. They update a single document completely or not at all.

Solution

  1. Step 1: Understand atomic writes scope

    Atomic writes in MongoDB apply only to single documents, ensuring full update or no update.
  2. Step 2: Compare with multi-document operations

    Multi-document updates require transactions, not atomic writes.
  3. Final Answer:

    They update a single document completely or not at all. -> Option D
  4. Quick Check:

    Atomic writes = single document update [OK]
Hint: Atomic writes affect one document fully or not at all [OK]
Common Mistakes:
  • Thinking atomic writes cover multiple documents
  • Confusing atomic writes with transactions
  • Assuming partial updates are atomic
2. Which of the following is the correct way to start a transaction in MongoDB using the shell?
easy
A. session.startTransaction()
B. db.startTransaction()
C. transaction.begin()
D. start.transaction()

Solution

  1. Step 1: Recall MongoDB transaction syntax

    Transactions start on a session object using startTransaction() method.
  2. Step 2: Verify options

    Only session.startTransaction() matches the correct syntax.
  3. Final Answer:

    session.startTransaction() -> Option A
  4. Quick Check:

    Start transaction = session.startTransaction() [OK]
Hint: Use session.startTransaction() to begin transactions [OK]
Common Mistakes:
  • Using db.startTransaction() which is invalid
  • Confusing method names like transaction.begin()
  • Incorrect method call syntax
3. Given the following code snippet, what will be the result if one update fails inside the transaction?
const session = client.startSession();
session.startTransaction();
try {
  await collection.updateOne({ _id: 1 }, { $set: { value: 10 } }, { session });
  await collection.updateOne({ _id: 2 }, { $set: { value: 20 } }, { session });
  await session.commitTransaction();
} catch (e) {
  await session.abortTransaction();
}
medium
A. Both updates are applied or none if any fails.
B. Only the first update is applied if the second fails.
C. Both updates are applied regardless of errors.
D. Updates are applied partially without rollback.

Solution

  1. Step 1: Understand transaction behavior

    Transactions ensure all operations succeed or all fail together.
  2. Step 2: Analyze code flow

    If any update fails, catch block aborts transaction, rolling back changes.
  3. Final Answer:

    Both updates are applied or none if any fails. -> Option A
  4. Quick Check:

    Transaction = all or nothing [OK]
Hint: Transactions commit all or rollback all changes [OK]
Common Mistakes:
  • Assuming partial updates apply on failure
  • Ignoring abortTransaction() effect
  • Thinking updates apply independently
4. Identify the error in this MongoDB transaction code snippet:
const session = client.startSession();
session.startTransaction();
await collection.updateOne({ _id: 1 }, { $set: { value: 10 } });
await session.commitTransaction();
session.endSession();
medium
A. updateOne cannot be used inside transactions.
B. Missing session option in updateOne call.
C. startTransaction() must be called after updateOne.
D. session.endSession() should be called before commitTransaction().

Solution

  1. Step 1: Check transaction usage in updateOne

    Operations inside a transaction must include the session option to link them.
  2. Step 2: Verify code calls

    updateOne lacks { session } option, so it runs outside transaction.
  3. Final Answer:

    Missing session option in updateOne call. -> Option B
  4. Quick Check:

    Include session in operations inside transactions [OK]
Hint: Always pass { session } to operations inside transactions [OK]
Common Mistakes:
  • Forgetting to pass session option in operations
  • Calling endSession before commitTransaction
  • Misordering startTransaction call
5. You need to update a user's profile document and also add a log entry in a separate collection. Which approach is best to ensure both updates succeed or fail together?
hard
A. Perform two separate atomic document writes without transactions.
B. Update the profile document atomically and ignore the log entry.
C. Use a transaction to update both collections atomically.
D. Update the log entry first, then the profile document without transactions.

Solution

  1. Step 1: Identify multi-document update requirement

    Updating two collections means multiple documents involved.
  2. Step 2: Choose appropriate method

    Transactions ensure both updates succeed or fail together, preserving consistency.
  3. Final Answer:

    Use a transaction to update both collections atomically. -> Option C
  4. Quick Check:

    Multi-document update = use transactions [OK]
Hint: Use transactions for multi-document atomic updates [OK]
Common Mistakes:
  • Using atomic writes for multiple collections
  • Ignoring failure possibility in one update
  • Assuming separate writes are automatically atomic