MongoDB Write Concern, Read Concern, and Read Preference
Fast recall
Quick revision
Core answer
w) controls how many replicas must acknowledge a write before the client sees success — w: 1 is fast, w: "majority" is durable. Read concern controls what writes a read can see — local returns latest including unreplicated, majority returns only majority-committed, linearizable joins the oplog to guarantee strict recency. Read preference routes reads to primary (strong) or secondaries (scalable, may be stale). The production default is w: majority + readConcern: majority — it survives a single-node failure without losing writes and reads never see uncommitted data.Whether you can translate abstract consistency theory into concrete MongoDB operational knobs and justify defaults
Using `w: 1` for financial writes, or believing `readPreference: secondary` gives better consistency than primary
Explain `linearizable` read concern's oplog-sync cost, mention `readConcern: snapshot` for transactions, and discuss majority write latency under partition
Interview-ready guide
Interview answer
Three knobs
- Write concern — how many replicas ack before success
- Read concern — how fresh must the read be
- Read preference — which node serves the read
Production defaults
w: majorityso writes survive a node failurereadConcern: majorityso reads never see rollback-able datareadPreference: primaryfor strong; secondary for analytics
Special modes
- Linearizable read concern is strongest, single-doc only, most expensive
- Snapshot read concern is used inside multi-document transactions
w: 0is for fire-hose telemetry, never for business data
Wrap up with the rule
w: majority+readConcern: majoritygives read-your-writes without paying linearizable cost — that is why modern drivers default to it
MongoDB Write Concern, Read Concern, and Read Preference
Direct Answer
MongoDB exposes three per-operation knobs that together define consistency and durability. Write concern (w) controls how many replicas must acknowledge a write before the client sees success — w: 1 is fast, w: "majority" is durable. Read concern controls what writes a read can see — local returns latest including unreplicated, majority returns only majority-committed, linearizable joins the oplog to guarantee strict recency. Read preference routes reads to primary (strong) or secondaries (scalable, may be stale). The production default is w: majority + readConcern: majority — it survives a single-node failure without losing writes and reads never see uncommitted data.
Common Mistakes & Pitfalls
Using w: 1 for financial writes, or believing readPreference: secondary gives better consistency than primary
Check your understanding
Answer these without looking back at the article.
- How does linearizable read concern detect a stale primary in a partition?
- What happens to pending writes with `w: majority` when the primary is partitioned from the majority?
- When would you use `readConcern: snapshot` outside of a transaction?
- How does `maxStalenessSeconds` actually get enforced by the driver?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.