Hoe beïnvloeden write concern en read concern de consistentie?

Question

Accepted Answer

**Write concern** en **read concern** controleren de consistentie- en duurzaamheidsgaranties in MongoDB (in replica sets) — waarbij wordt ingeruild tussen **performance** en **veiligheid/consistentie**. Ze stellen je in staat om af te stemmen hoe sterk writes worden bevestigd en hoe consistent reads zijn, op basis van de behoeften van de gegevens.

## Write concern — duurzaamheid van writes

```js
// write concern: how many nodes must acknowledge a write
db.orders.insertOne(doc, { writeConcern: { w: 1 } });           // primary only — fast
db.orders.insertOne(doc, { writeConcern: { w: "majority" } });   // majority of nodes — safe
db.orders.insertOne(doc, { writeConcern: { w: "majority", j: true } }); // + journaled to disk
```

```text
w: 1          → only the PRIMARY acknowledges (fast, but a write could be LOST on failover)
w: "majority" → a majority of nodes acknowledge → the write SURVIVES primary failover
               (no data loss) — safer but slower (waits for replication)
j: true       → also wait for the write to be written to the JOURNAL (disk durability)
```

**Write concern** controleert duurzaamheid: `w: "majority"` zorgt ervoor dat de write wordt gerepliceerd naar een meerderheid (overleven failover zonder verlies), maar is langzamer; `w: 1` is sneller maar een write zou kunnen verloren gaan als de primary faalt voordat replicatie plaatsvindt.

## Read concern — consistentie van reads

```js
db.orders.find().readConcern("majority");   // read data acknowledged by a majority
```

```text
local        → returns the most recent data on the node (may not be majority-committed,
               could be rolled back) — default, fast
majority     → returns only data acknowledged by a majority (won't be rolled back) — consistent
linearizable → strongest (reflects all prior majority writes) — slowest
```

**Read concern** controleert welke gegevens reads zien: `majority` retourneert alleen data die door een meerderheid is gecommit (wordt niet teruggedraaid — consistent), versus `local` (de meest recente lokale gegevens, mogelijk nog niet door een meerderheid gecommit).

## De consistentie versus performance trade-off

```text
Stronger guarantees (w: majority, readConcern: majority) → safer, consistent, but SLOWER
Weaker guarantees (w: 1, readConcern: local) → faster, but risk of data loss on failover
  or reading not-yet-durable data
→ Choose based on the data: critical data (payments) → strong; less critical → faster.
→ Reading from secondaries adds eventual-consistency considerations (stale reads).
```

## Waarom het belangrijk is

Het begrijpen van write concern en read concern is belangrijk voor **het beheren van de consistentie-versus-performance trade-off** in MongoDB replica sets, dus het is waardevol kennis op senior-niveau voor het bouwen van correcte, adequaat afgestemde gedistribueerde MongoDB-applicaties.

Deze instellingen controleren MongoDB's consistentie- en duurzaamheidsgaranties, en het begrijpen ervan is noodzakelijk om ervoor te zorgen dat gegevens met het juiste veiligheidsniveau worden behandeld voor hun belang. **Write concern** is vooral belangrijk voor **duurzaamheid**: `w: "majority"` zorgt ervoor dat een write wordt gerepliceerd naar een meerderheid van nodes (overleven van primary failover zonder gegevensverlies — kritiek voor belangrijke gegevens zoals betalingen of orders), terwijl `w: 1` sneller is maar het risico loopt een write te verliezen als de primary faalt voordat replicatie plaatsvindt — een significante trade-off waarbij een verkeerde keuze stille gegevensverlies bij failover zou kunnen betekenen. **Read concern** controleert **read-consistentie**: `majority` retourneert alleen data die door een meerderheid is gecommit (consistent, wordt niet teruggedraaid) versus `local` (de meest recente gegevens, mogelijk nog niet duurzaam en onderhevig aan rollback) — wat van invloed is op of reads gegevens kunnen zien die later verdwijnen.

Het begrijpen van de **trade-off** — sterkere garanties (majority) zijn veiliger en consistenter maar langzamer, terwijl zwakkere garanties sneller zijn maar risico op gegevensverlies of inconsistente reads meebrengen — en het kiezen op basis van het kritieke karakter van de gegevens (sterk voor belangrijke gegevens, sneller voor minder kritieke) is de sleutelbeslissing.

Ook relevant is dat reads van secondaries eventual-consistency-overwegingen toevoegen (verouderde reads).

Omdat gegevensconsistentie en duurzaamheid kritiek zijn (en het juiste niveau afhangt van de gegevens), en omdat write/read concern de manier is waarop je deze garanties tegen performance afstemt in MongoDB's gedistribueerde (replica set) architectuur, is het begrijpen ervan — de duurzaamheids-/consistentieniveaus, de performance trade-off, en passend kiezen — belangrijk kennis op senior-niveau voor het bouwen van correcte gedistribueerde MongoDB-applicaties, een onderwerp dat aantoont dat je gedistribueerde-systemen consistentie trade-offs begrijpt, wat vooral belangrijk is voor applicaties waar gegevensverlies of inconsistentie kostbaar zou zijn.