MongoDB Multi-Document ACID Transactions
Fast recall
Quick revision
Core answer
WriteConflict and must retry. In Spring Boot you register a `MongoTransactionManager` bean and annotate service methods with `@Transactional`. The realities: transactions require a replica set (not standalone), have a default 60-second timeout, add WiredTiger cache pressure, and should be used only when cross-document atomicity is genuinely required — single-document writes are always atomic natively.Understanding when MongoDB transactions are genuinely needed and the operational cost of using them
Using transactions for every write, or attempting them on a standalone `mongod`
Mention MVCC snapshot isolation, `withTransaction` retry loop on `TransientTransactionError`, the 60s limit, and sharded cluster two-phase commit cost
Interview-ready guide
Interview answer
State the capability
- MongoDB supports multi-document ACID since 4.0 (replica set) and 4.2 (sharded cluster)
- Snapshot isolation via MVCC
Give the Spring recipe
- Register
MongoTransactionManagerbean - Use
@Transactionalon service methods - Requires replica set — standalone mongod won't work
Show the driver idiom
session.withTransaction(...)auto-retries transient errors- Read concern
snapshot, write concernmajority
Close with the discipline
- Single-doc writes are atomic natively — don't wrap every write
- 60s timeout; keep transactions short
- Sharded transactions use 2PC — more expensive; design to avoid
MongoDB Multi-Document ACID Transactions
Direct Answer
Since MongoDB 4.0 (replica sets) and 4.2 (sharded clusters), multi-document transactions deliver ACID across documents and collections. They use snapshot isolation and MVCC; reads inside the transaction see a consistent snapshot from the moment it started, and conflicting concurrent writes raise WriteConflict and must retry. In Spring Boot you register a MongoTransactionManager bean and annotate service methods with @Transactional. The realities: transactions require a replica set (not standalone), have a default 60-second timeout, add WiredTiger cache pressure, and should be used only when cross-document atomicity is genuinely required — single-document writes are always atomic natively.
Common Mistakes & Pitfalls
Using transactions for every write, or attempting them on a standalone mongod
Check your understanding
Answer these without looking back at the article.
- How does `withTransaction` decide which errors to retry?
- What happens to replication lag when a long transaction holds an oplog entry?
- When is the subset pattern a better answer than a multi-document transaction?
- How do shard-key choices affect cross-shard transaction latency?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.