Explain 'Write Conflict' errors during a transaction. How should your Node.js application handle them?

Write Conflict errors occur when two concurrent transactions attempt to modify the same document, causing one to fail due to MongoDB's optimistic locking. Node.js applications should handle them using retry logic with exponential backoff, leveraging the driver's built-in callback API where possible.

Write Conflict errors in MongoDB transactions are a consequence of the snapshot isolation model used to ensure data consistency . When two concurrent transactions attempt to modify the same document, the first transaction acquires the necessary lock, and the second transaction receives a "WriteConflict" error upon trying to commit . This error indicates that the operation cannot complete because another transaction has already modified the data this transaction depends on . These conflicts are considered transient by nature—they are temporary and if you restart the transaction, it may succeed on the next attempt .

This scenario commonly occurs in high-concurrency applications where multiple users or processes interact with the same data simultaneously. For example, when two users view the same article and trigger transactions that update that article's metadata, the second transaction may abort if the first hasn't completed . The default lock request timeout is 5ms, after which new transactions attempting to access the same data will abort .

The MongoDB Node.js driver provides two primary APIs for working with transactions: the Callback API and the Core API . The Callback API is recommended for most use cases as it automatically incorporates retry logic for Write Conflict errors .

Using the Callback API with Automatic Retry

The withTransaction method automatically retries the entire transaction if a TransientTransactionError (which includes WriteConflict) occurs, and also retries the commit operation if an UnknownTransactionCommitResult error occurs . This retry logic continues until a configurable timeout (default 60 seconds) or until the operation succeeds .

If you need more control over the retry behavior, you can use the Core API and implement your own retry logic . This is useful when you need custom backoff strategies or want to incorporate business logic between retry attempts.

Manual Retry Implementation

Important Considerations for Handling Write Conflicts

1
WriteConflict errors are expected under normal concurrency and are not indicative of a problem with your application—they are part of MongoDB's MVCC concurrency control .
2
Always check for WriteConflict errors specifically (error code 112) before retrying, as not all transaction errors are transient .
3
Implement exponential backoff between retry attempts to avoid overwhelming the system with repeated conflicting transactions .
4
Consider whether a transaction is truly necessary—if you can accomplish your task with atomic single-document updates, you can avoid WriteConflict errors entirely .
5
Keep transactions short and limit the number of operations to reduce the window for conflicts .
6
When using Mongoose, be aware that document state may not automatically reset after a transaction abort; you may need to manually refresh documents before retrying .

Write Conflict errors are a normal and expected part of working with MongoDB transactions. The Node.js driver's withTransaction method provides automatic retry logic that handles most cases effectively. For applications requiring custom control, implementing manual retry with exponential backoff is straightforward. The key is to recognize that these conflicts are transient and to design your application to gracefully retry operations rather than treating them as fatal errors .

Difficulty: 6/10

Topics: transactions, write conflicts, retry logic

Scenario Questions

0-2 years experience

1
You need to insert a document inside a MongoDB transaction using the Node.js driver, and you get a write conflict error. How would you modify your code to handle it?
2
If two concurrent requests try to update the same document within separate transactions, what will MongoDB return, and what should your Node.js handler do immediately after receiving that error?

2-5 years experience

1
During a feature rollout, you notice occasional write conflict errors in your logs when multiple services update inventory. Walk me through how you'd investigate and decide whether to add a retry or change the transaction logic.
2
Your team added a new index to improve query speed, but now write conflicts are happening more often. Why might that be, and how would you adjust your Node.js transaction handling?

5-8 years experience

1
Design a robust retry mechanism for write conflict errors in a high‑throughput Node.js service that uses MongoDB transactions. What back‑off strategy would you choose and why?
2
Explain how you would monitor and alert on write conflict rates across microservices, and what architectural changes you might make if the rate exceeds a threshold.

8+ years experience

1
At a company-wide level, we’re moving from single‑document updates to multi‑document transactions. How would you evolve our data model and Node.js transaction patterns to minimize write conflicts while preserving consistency?
2
Discuss the trade‑offs of using optimistic concurrency control versus MongoDB’s built‑in transaction write conflict handling in a distributed system, and how you’d guide teams to adopt a consistent strategy.

Follow-up Questions

❓Can you sketch the retry code you’d use?
❓What could happen if you retry without a back‑off?
❓How would you verify that your solution doesn’t introduce duplicate writes?