Programming Tutorials

  You have migrated a critical workflow to MongoDB 5.0+ or 6.0+, leveraged multi-document ACID transactions across a sharded cluster, and now your logs are flooding with this: { "code": 112, "codeName": "WriteConflict", "errorLabels": ["TransientTransactionError"], "errmsg": "WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction." } In a high-throughput environment, simply "retrying" without a strategy results in a thundering herd problem, spiking CPU usage and locking latency. This post details the mechanics of WiredTiger conflicts and provides a production-grade implementation for handling them in Node.js/TypeScript. The Root Cause: WiredTiger Snapshot Isolation To fix the error, you must understand the storage engine. MongoDB uses WiredTiger, which employs  Multi-Version Concurrency Control (MVCC)  using Snapshot Isolation...

  You have likely encountered this error in your logs, usually causing a 500 status code on a production endpoint: Error Code 16819:  Sort exceeded memory limit of 104857600 bytes, but did not opt in to external sorting. Aborting operation. The immediate reaction is often to add  { allowDiskUse: true }  to the aggregation options. While this eliminates the error, it is a performance patch, not a fix. It forces MongoDB to spill the data into temporary files on the disk to perform the sort. Disk I/O is orders of magnitude slower than RAM, meaning you have successfully traded a crash for high latency. To truly fix this—and scale your application—you must optimize your indexing strategy to avoid the in-memory sort entirely. The Root Cause: Blocking Sort MongoDB has a strict internal limit of  100MB  of RAM for blocking sort operations. A  Blocking Sort  occurs when the execution plan cannot obtain the sort order from an index. Consequently, MongoDB mu...