MongoDB Replica Sets and Read Preferences
Fast recall
Quick revision
Core answer
mongod processes holding the same data — one primary accepts all writes, multiple secondaries tail the primary's oplog, and an optional arbiter votes in elections but stores no data. On primary failure the set elects a new primary within ~10s from the members with the most current oplog position. Read preferences route reads: primary (strong), primaryPreferred, secondary (offload, may be stale), secondaryPreferred, nearest (lowest latency). Combined with `writeConcern: majority` and `readConcern: majority`, you get durable, read-your-writes behavior. In Spring Boot you set the preference on the MongoClient connection string or override per MongoTemplate.Understanding of HA, failover, and the consistency-vs-latency trade-off introduced by secondary reads
Using `readPreference: secondary` for read-your-writes, ignoring replication lag, or using arbiters in production voting critical configurations
Explain majority write concern, `maxStalenessSeconds`, election timing, Hidden/Delayed secondary roles, and multi-region read routing
Interview-ready guide
Interview answer
Describe the topology
- Primary + secondaries + optional arbiter
- Writes to primary, async replication via oplog
- Election in ~10s on primary failure
Cover read preferences
primary(default),primaryPreferred,secondary,secondaryPreferred,nearest- Each trades consistency for latency or load offload
Mention write/read concerns
w: majority+readConcern: majorityfor durable read-your-writeslinearizableread concern for strict recency (single-doc only)
Call out gotchas
- Replication lag on secondaries — use
maxStalenessSeconds - Avoid arbiters where durability matters
- Retry
NotPrimaryduring elections
Close with Spring config
- Connection string or programmatic MongoClient settings
- Per-template beans for analytics (
secondaryPreferred) - Per-query overrides when needed
MongoDB Replica Sets and Read Preferences
Direct Answer
A replica set is a group of mongod processes holding the same data — one primary accepts all writes, multiple secondaries tail the primary's oplog, and an optional arbiter votes in elections but stores no data. On primary failure the set elects a new primary within ~10s from the members with the most current oplog position. Read preferences route reads: primary (strong), primaryPreferred, secondary (offload, may be stale), secondaryPreferred, nearest (lowest latency). Combined with writeConcern: majority and readConcern: majority, you get durable, read-your-writes behavior. In Spring Boot you set the preference on the MongoClient connection string or override per MongoTemplate.
Common Mistakes & Pitfalls
Using readPreference: secondary for read-your-writes, ignoring replication lag, or using arbiters in production voting critical configurations
Check your understanding
Answer these without looking back at the article.
- Why do arbiters reduce durability despite making elections possible with fewer data nodes?
- How does `readConcern: majority` interact with secondary reads?
- What's the purpose of a delayed secondary and how do you configure one?
- How do you design a replica set for multi-region HA with low write 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.