What happens to a MongoDB transaction that runs longer than transactionLifetimeLimitSeconds?

## The limit and what it does `transactionLifetimeLimitSeconds` is a server parameter with a default of 60 seconds. A periodic server task looks for transactions whose lifetime has exceeded it and aborts them. From the application's point of view, the next operation you send on that transaction — or the commit — fails, and the work is gone. Nothing is partially applied: abort is abort. The driver side has its own clock too. `maxCommitTimeMS` bounds how long the commit may take, and `withTransaction()` gives up retrying after roughly two minutes. A transaction can therefore end because your callback was slow, because the commit was slow, or because the server's lifetime limit expired first. ## Why MongoDB caps it at all An open transaction is not free while it sits there: - It holds a **storage-engine snapshot**. Every document version that existed when the snapshot was taken must remain reachable for as long as the transaction lives, so cache and history accumulate instead of being reclaimed. - It holds **locks** on everything it has written. Other transactions that touch the same documents cannot proceed. - Its writes are **staged** and become visible only at commit, so the longer it runs the larger the eventual burst. Without a cap, one forgotten transaction — a client that opened one and then blocked on a slow HTTP call — would degrade the whole node. The 60-second default is the server refusing to let a single misbehaving client do that. ## Fast failure on conflict, by design Related and often conflated: `maxTransactionLockRequestTimeoutMillis` defaults to 5 milliseconds. A transaction that finds a document locked by another transaction does not queue behind it for long; it fails quickly with a write conflict, which the driver sees carrying the transient-transaction label, and `withTransaction()` re-runs the whole thing. MongoDB prefers a cheap retry over a long wait. The operational signature of a hot document under transactional load is therefore not slow queries but a rising retry rate — and eventually the retry limit being hit. ## The oplog story Older MongoDB versions required an entire transaction to fit in a single oplog entry, which imposed an effective 16 MB ceiling on the transaction's total change set. That constraint is gone: since MongoDB 4.2 a large transaction is written as as many oplog entries as it needs. The 16 MB BSON limit still applies to each individual document, but it no longer caps the transaction. What replaces it is a softer, more operational limit. All of a large transaction's oplog entries become visible together at commit, so committing a very large transaction produces a burst of replication traffic. Secondaries apply it as a unit, lag spikes, and the majority-commit point — which every `w: "majority"` write in the system waits on — moves later. A single 200,000-document transaction can therefore be felt by unrelated traffic. MongoDB's own guidance is to keep a transaction to about 1,000 documents or fewer. ## What to do instead **Shrink the transaction.** Most oversized transactions are doing bulk work that has no cross-document invariant at all — a backfill, a status sweep. That work does not need a transaction; it needs an idempotent, resumable batch loop with a checkpoint (the last processed `_id`), so a failure resumes rather than restarts. **Move work out of the transaction.** Anything that is not a database operation — reading a file, calling a service, computing a large payload — should happen before the transaction opens. A transaction should be a tight burst of database operations, not the scope of a business workflow. **Model the invariant into one document** where you can, so the atomic write is free and there is no lifetime to exceed. **Only then consider the knob.** Raising `transactionLifetimeLimitSeconds` is legitimate for a specific, understood workload — a controlled migration on a maintenance window, for instance — but as a response to "our transactions time out" it converts a fast, visible failure into slow cache pressure and long lock holds that are much harder to diagnose. ## Diagnosing it The error surfaces as the transaction having been aborted or no longer existing. Look at how long the callback actually takes end to end, whether anything non-database sits inside it, how many documents it touches, and whether the abort rate correlates with contention on a small set of hot documents. `currentOp` shows transactions in progress with their start time, which is the quickest way to catch a client holding one open. ## What an interviewer is testing Whether you treat the limit as an obstacle or as a signal. The good answer states the default, explains the snapshot-and-lock cost that motivates it, mentions that the old 16 MB oplog ceiling is gone but that big commits still hurt replication, and lands on restructuring the work rather than raising the parameter.