What is MongoDB's read concern?
Why Interviewers Ask This
Candidates at the intermediate level are expected to not only know this concept but explain the trade-offs involved. Interviewers use this question to see if you can reason about design decisions, not just recall facts.
Answer
Read concern controls the consistency and isolation of data returned by read operations — which version of data is visible to a read. Read concern levels: local (default): returns the most recent data on the queried server. For primaries: data may not be replicated to majority. May be rolled back if primary fails before replication. available: same as local for replica sets; for sharded clusters, returns data from local shard even if rebalancing. May return orphaned data. majority: returns data acknowledged by a majority of replica set members — data will not be rolled back. Requires enableMajorityReadConcern (default true). Might return slightly older data than "local." linearizable: most strict — reads reflect all successful majority-acknowledged writes before the read. Slower — may wait for replication. Only for primary reads. snapshot: for transactions — reads from a consistent snapshot taken at the start of the transaction. Available in multi-document transactions and "majority" committed. Choosing read concern: local — high performance, slight staleness acceptable; majority — strong consistency, data won't be rolled back; linearizable — strongest, real-time read; snapshot — use in transactions. Setting: db.orders.find({}).readConcern("majority"). Combine write concern and read concern for strong consistency: write with w:"majority" and read with rc:"majority".
Common Mistake
Many candidates answer correctly but can't explain the 'why'. Always be prepared to justify your answer with a concrete example or use case from your MongoDB experience.