Configuring Read Concerns

1. Using local Read Concern

Aspect	Detail
Default for primary reads	Latest local data
Durability	Not guaranteed; data may be rolled back

2. Using available Read Concern

Aspect	Detail
Default for secondary	Lowest latency
Sharded	May return orphans (no shard version check)

3. Using majority Read Concern

Guarantee	Detail
Visibility	Only data acknowledged by majority
Durable	Will not be rolled back
Cost	Slight latency for snapshot resolution

4. Using linearizable Read Concern

Aspect	Detail
Guarantee	Reflects all majority-committed writes before read started
Restriction	Only on primary, single-doc reads
Cost	Higher; performs no-op write to majority

5. Using snapshot Read Concern

Aspect	Detail
Use in	Multi-document transactions
Guarantee	Reads from single point-in-time snapshot
Outside txn	Available on mongos for analytical reads

6. Understanding Read Concern Levels

Level	Visibility	Durability
local	Latest	No
available	Latest (sharded fast)	No
majority	Majority-committed	Yes
linearizable	Real-time	Yes
snapshot	Snapshot at cluster time	Yes

7. Setting Read Concern in Operations

API	Example
find	find().readConcern({level:"majority"})
aggregate	Pass readConcern in options
Session	Default for ops in the session

8. Combining Read Concern with Read Preference

Combo	Use Case
majority + primary	Strongly consistent
majority + secondaryPreferred	Read scale + durability
local + secondary	Lowest latency, may be stale

9. Using Read Concern with Transactions

Allowed	Detail
snapshot	Most common
majority	Default if not set
local	Allowed; fastest, weaker consistency

10. Understanding Read Concern Performance

Level	Cost
local / available	Lowest
majority	Slight; uses storage snapshot
linearizable	Highest; round-trips majority
snapshot	Moderate; opens transaction snapshot