How do MongoDB's five readPreference modes differ in which members they route reads to?

## What read preference selects Read preference tells the driver **which replica set member a read may be sent to**. It is purely about member selection; how fresh or how durable the returned data must be is controlled separately by read concern. In a sharded cluster the same preference is honoured by the router when it fans out to each shard's replica set. ## The five modes **`primary`** — the default. Reads go to the primary only. If there is no primary (mid-election, or a set that cannot form a majority), the read **errors** rather than falling back. This mode gives the freshest data and, in the absence of a rollback, lets you read your own writes without extra machinery. **`primaryPreferred`** — the primary when one exists, otherwise an eligible secondary. Useful when you want fresh reads normally but would rather serve slightly stale data than fail during a failover window. **`secondary`** — eligible secondaries only, never the primary; errors if none qualifies. Used to keep a workload strictly off the primary, for example a reporting or export job. **`secondaryPreferred`** — eligible secondaries when available, the primary as a fallback. This is the common choice for read-heavy analytical traffic that must not fail if secondaries are unavailable. **`nearest`** — role-blind. The driver considers **all** eligible members, primary included, and chooses on measured network latency. This is the mode for latency-sensitive geo-distributed reads where you care about proximity, not about which member is the leader. ## How the driver actually picks Drivers continuously monitor each member with heartbeats and keep a round-trip-time estimate per member. Selection proceeds in stages: filter by mode (which roles are allowed), then by `maxStalenessSeconds` if given, then by tag sets if given, and finally choose among the survivors within a **latency window** — the fastest eligible member's round-trip time plus a configurable threshold (`localThresholdMS`, 15 ms by default), with a random pick inside that window to spread load. This is why `nearest` does not mean "strictly the single closest member" but "one of the members that are about as close as the closest". ## Tag sets Members can carry arbitrary key/value tags in the replica set configuration — `{ region: "eu", use: "reporting" }`, for example. A read preference can then supply an ordered list of tag sets; the driver tries the first set, and only if no member matches does it move to the next. This is how you pin analytics traffic to a dedicated member, or keep reads inside a region. Tag sets cannot be combined with the `primary` mode, since there is only ever one primary and no choice to make. ## `maxStalenessSeconds` Because secondaries apply the oplog asynchronously, a badly lagging member is still "eligible" under a plain `secondaryPreferred`. `maxStalenessSeconds` sets an upper bound: members estimated to be further behind than that value are excluded from selection. The value has a floor — it must be at least 90 seconds — because the estimate is derived from heartbeats and periodic no-op writes, and a tighter bound could not be computed reliably. Like tag sets, it cannot be used with the `primary` mode. Note what it is not: a freshness guarantee, only a coarse exclusion of badly lagging members. ## What secondary reads cost you Three things routinely surprise teams. First, **staleness**: any non-primary read may return an older view, so the write you just made may be invisible. Fixing that properly needs causally consistent sessions or a primary read, not a read preference tweak. Second, **secondaries do the same write work**: every secondary applies the full oplog. Offloading reads relieves the primary's read load but adds nothing to write capacity, so "add a secondary to scale" only helps read-bound workloads. Third, **failure behaviour differs by mode**: `primary` fails closed during an election, while `secondaryPreferred` keeps serving — which is a feature for a dashboard and a hazard for a balance check. ## Where to set it Read preference can be set on the connection string (`readPreference=secondaryPreferred&maxStalenessSeconds=120`), on a client, database or collection handle, or on the individual operation, with the most specific level winning. Setting it globally on the connection string is convenient but blunt: it silently applies to reads that genuinely need the primary, which is why per-operation overrides on the sensitive paths are the safer pattern.