Comment les write concern et read concern affectent-ils la cohérence des données ?

Question

Accepted Answer

**Write concern** et **read concern** contrôlent les garanties de cohérence et de durabilité dans MongoDB (dans les replica sets) — en établissant un compromis entre **performance** et **sécurité/cohérence**. Ils vous permettent de paramétrer la force de la confirmation des écritures et la cohérence des lectures, en fonction des besoins des données.

## Write concern — durabilité des écritures

```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** contrôle la durabilité : `w: "majority"` garantit que l'écriture est répliquée vers une majorité (survit au basculement sans perte), mais est plus lente ; `w: 1` est plus rapide, mais une écriture pourrait être perdue si le primary échoue avant la réplication.

## Read concern — cohérence des lectures

```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** contrôle quelles données les lectures voient : `majority` retourne uniquement les données validées par une majorité (ne seront pas annulées — cohérentes), versus `local` (les dernières données locales, possiblement pas encore validées par une majorité).

## Le compromis cohérence versus performance

```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).
```

## Pourquoi c'est important

Comprendre write concern et read concern est important pour **gérer le compromis cohérence-versus-performance** dans les replica sets MongoDB, ce qui en fait une connaissance de haut niveau précieuse pour construire des applications MongoDB distribuées correctes et correctement paramétrées.

Ces paramètres contrôlent les garanties de cohérence et de durabilité de MongoDB, et les comprendre est nécessaire pour s'assurer que les données sont manipulées avec le bon niveau de sécurité pour leur importance. **Write concern** est particulièrement important pour la **durabilité** : `w: "majority"` garantit qu'une écriture est répliquée vers une majorité de nœuds (survivant au basculement du primary sans perte de données — critique pour les données importantes comme les paiements ou les commandes), tandis que `w: 1` est plus rapide mais risque la perte d'une écriture si le primary échoue avant la réplication — un compromis conséquent où mal choisir pourrait signifier une perte silencieuse de données au basculement. **Read concern** contrôle la **cohérence des lectures** : `majority` retourne uniquement les données validées par une majorité (cohérentes, ne seront pas annulées) versus `local` (les dernières données, possiblement pas encore durables et sujettes à annulation) — affectant si les lectures pourraient voir des données qui disparaîtraient plus tard.

Comprendre le **compromis** — les garanties plus fortes (majority) sont plus sûres et cohérentes mais plus lentes, tandis que les plus faibles sont plus rapides mais risquent la perte de données ou des lectures incohérentes — et choisir en fonction de la criticité des données (fort pour les données importantes, plus rapide pour les moins critiques) est le jugement clé.

Il est aussi pertinent de noter que la lecture depuis les secondaires ajoute des considérations de cohérence éventuelle (lectures obsolètes).

Puisque la cohérence et la durabilité des données sont critiques (et le bon niveau dépend des données), et puisque write/read concern sont la façon de paramétrer ces garanties contre la performance dans l'architecture distribuée (replica set) de MongoDB, les comprendre — les niveaux de durabilité/cohérence, le compromis de performance, et bien choisir — est une connaissance de haut niveau importante pour construire des applications MongoDB distribuées correctes, un sujet démontrant la compréhension des compromis de cohérence des systèmes distribués qui est particulièrement important pour les applications où la perte de données ou l'incohérence serait coûteuse.