Read Concern and Write Concern

What we're doing: Show a write concern choice tied to what the data is worth protecting.

// A financial transaction — worth the extra latency for durability
db.payments.insertOne(
  { userId, amount, status: "completed" },
  { writeConcern: { w: "majority", j: true } }
)

// A high-volume, low-stakes analytics event — default write concern is fine
db.pageViews.insertOne({ userId, path, at: new Date() })

2

w: "majority" with j: true means the payment is acknowledged only once a majority of members have it durably on disk — losing it on a primary failure would require losing a majority at once.

7

A page view is cheap to lose and expensive to slow down at this volume — the default write concern trades some durability risk for much lower latency, which fits data this disposable.

Why this works: The right write concern is a direct function of what the data is worth — the same choice ("majority" for everything, or "1" for everything) is wrong in one direction or the other for a system handling both payments and page-view analytics.

What we're doing: Show a write concern timeout occurring and clarify what it does and does not mean.

try {
  await db.orders.insertOne(order, {
    writeConcern: { w: "majority", wtimeout: 3000 }
  })
} catch (err) {
  if (err.name === "MongoServerError" && err.codeName === "WriteConcernTimeout") {
    // The write may still have applied on the primary — it just was not
    // confirmed by a majority within 3 seconds. Do not assume it failed.
  }
}

8

A WriteConcernTimeout means the requested acknowledgement level was not confirmed in time — it is not the same as the write never having happened.

Why this works: wtimeout bounds how long the caller waits, not what the database does with the write itself — treating a timeout as "definitely failed, retry the insert" risks a duplicate if the original write does eventually propagate.

What we're doing: Contrast a dashboard read (local is fine) against a read that must not reflect data that could still roll back (majority).

// A live dashboard — local is fine, slightly-unconfirmed data is an acceptable trade for speed
db.metrics.find({ ... }).readConcern("local")

// Confirming a payment actually posted before releasing goods — must not be data that could roll back
db.payments.findOne({ _id: paymentId }, { readConcern: { level: "majority" } })

2

A dashboard refreshing every few seconds does not need each read guaranteed unrollbackable — local's lower latency is the better trade here.

5

Releasing goods based on a payment record that could still be rolled back on a failover would be a real business risk — majority read concern rules that out.

Why this works: The read concern decision mirrors the write concern one: match the strength of the guarantee to what is actually at risk if the guarantee turns out to be wrong, not to a single default applied everywhere.

What we're doing: Show the availability cost of "majority" concretely during a partition, and why it is still the right choice for certain writes.

// Normal operation: 3-member replica set, majority = 2
// A network partition isolates the primary with 1 other member (2 of 3 — majority still reachable): writes proceed

// A worse partition isolates the primary alone (1 of 3 — no majority reachable):
// w: "majority" writes now block/timeout — the system correctly refuses to
// falsely acknowledge a payment write it cannot durably confirm

4

This is the trade-off made explicit: refusing to proceed under this partition is exactly what protects a payment write from being acknowledged and then silently lost.

Why this works: The unavailability here is not a bug — it is majority write concern doing precisely what it promises: never reporting success for a write it cannot guarantee will survive a failover, even if that means temporarily refusing writes during a severe partition.