How would you choose cluster-wide default read and write concerns for a platform with mixed workloads?

## What is actually being decided The dials are few — `w`, `j` and `wtimeout` on writes, read concern level and read preference on reads — but a platform decision has three parts: what the **cluster default** is, what an application may **override**, and how you **detect** that the effective settings have drifted from the intent. ## Set defaults explicitly The `setDefaultRWConcern` administrative command (available since MongoDB 4.4) sets a cluster-wide default write concern and default read concern, and `getDefaultRWConcern` reports the current values including whether they came from your setting or from the server's implicit default. Setting them explicitly is worth doing even when it matches the implicit default, because it makes the intent auditable and survives topology changes that would otherwise move the implicit value underneath you. The design principle is **safe by default, downgrade by exception**. A default of `majority` means the failure mode of a forgetful developer is a slightly slower write, not a silently losable one. The reverse — a fast default with the important paths expected to opt up — fails in the direction that costs you data. ## Tiering by workload A workable classification: - **Ledger-like data** (payments, entitlements, audit): `w: "majority"`, always, plus a `wtimeout` so a degraded set fails visibly instead of hanging. Reads that gate an irreversible external action use `readConcern: "majority"`. - **Core application state** (users, orders, content): the `majority` default, `local` reads, primary reads on write-then-read flows. - **High-volume derived or disposable data** (clickstream, metrics, cache-like collections): a documented `w: 1` override on that collection's client, never `w: 0` unless the loss of error reporting is genuinely acceptable. - **Reporting and analytics**: unchanged write concern, reads moved to secondaries with a staleness bound and tags, so the primary is protected. The important organisational move is that the downgrade lives **next to the code that owns the data**, is visible in review, and can be greped for. A global weak default hides the same decision everywhere. ## The arbiter trap Since MongoDB 5.0 the implicit default write concern is `majority`, **except** in sets containing arbiters where the data-bearing voting members do not themselves form a majority of the voting members — there it drops to `w: 1`. A team that adds an arbiter to save the cost of a third data-bearing member has therefore changed the durability posture of every write in the cluster without touching any application code. If you run such a topology deliberately, set the default explicitly so the choice is recorded, and understand that majority writes will also stall whenever the single secondary is down. ## Latency budgets and topology Majority write latency is the round trip to the slowest member of the fastest majority. When that number is unacceptable, the reflex to weaken `w` is usually the wrong lever. Better lever order: 1. Place enough data-bearing members close to the primary that a majority can be formed locally; keep distant members as additional copies beyond the majority. 2. Reduce the write rate per document, batch, or shard the workload. 3. Only then consider a per-collection downgrade, and only for data whose loss you have written down as acceptable. Measure before deciding: track write latency percentiles with and without majority acknowledgment, and track the lag of the majority commit point behind the primary's newest write. If that lag is spiky, majority writes will be spiky no matter how you tune the application. ## What must not be weakened Some features depend on the majority commit point rather than on your preference — change streams only surface events once they are majority-committed, so an unhealthy majority commit point degrades those consumers regardless of the write concern an individual write used. In currently-shipping versions majority read concern is always enabled and cannot be turned off. ## Governance Three practices keep the policy real: - **Assert the defaults.** Have a startup check or a periodic job read the cluster defaults and alarm when they differ from the documented policy. - **Make overrides explicit and searchable.** A weak write concern should appear in code, not in a connection string buried in a deployment template where nobody reads it. - **Alert on write concern errors.** A rising rate is the earliest signal that the durability you promised is not being met, and it is far more actionable than a lagging-secondary dashboard nobody watches. The judgment being tested here is not knowledge of the syntax. It is whether you treat durability as a per-workload product decision with a written rationale, or as a latency knob that gets turned during an incident and never turned back.