Come influiscono la write concern e la read concern sulla consistenza?

Question

Accepted Answer

**Write concern** e **read concern** controllano le garanzie di consistenza e durabilità in MongoDB (nei replica set) — facendo compromessi tra **performance** e **sicurezza/consistenza**. Ti permettono di calibrare quanto fortemente le scritture sono confermate e quanto coerenti sono le letture, in base alle esigenze dei dati.

## Write concern — durabilità delle scritture

```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** controlla la durabilità: `w: "majority"` assicura che la scrittura sia replicata a una maggioranza (sopravvive al failover senza perdita) ma è più lenta; `w: 1` è più veloce ma una scrittura potrebbe andare persa se il primary fallisce prima della replicazione.

## Read concern — consistenza delle letture

```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** controlla quali dati vedono le letture: `majority` restituisce solo i dati confermati dalla maggioranza (non verranno annullati — consistente), versus `local` (i dati locali più recenti, possibilmente non ancora confermati dalla maggioranza).

## Il compromesso tra consistenza e 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).
```

## Perché è importante

Comprendere write concern e read concern è importante per **gestire il compromesso tra consistenza e performance** nei replica set di MongoDB, perciò è una conoscenza preziosa a livello senior per costruire applicazioni MongoDB distribuite corrette e adeguatamente ottimizzate.

Queste impostazioni controllano le garanzie di consistenza e durabilità di MongoDB, e comprenderle è necessario per assicurare che i dati siano gestiti con il giusto livello di sicurezza per la loro importanza. **Write concern** è particolarmente importante per la **durabilità**: `w: "majority"` assicura che una scrittura sia replicata a una maggioranza di nodi (sopravvive al failover del primary senza perdita di dati — critico per dati importanti come pagamenti o ordini), mentre `w: 1` è più veloce ma rischia di perdere una scrittura se il primary fallisce prima della replicazione — un compromesso significativo dove scegliere male potrebbe significare perdita silenziosa di dati al failover. **Read concern** controlla la **consistenza della lettura**: `majority` restituisce solo dati confermati dalla maggioranza (consistente, non verranno annullati) versus `local` (i dati più recenti, possibilmente non ancora durevoli e soggetti ad annullamento) — influenzando se le letture potrebbero vedere dati che successivamente scompaiono.

Comprendere il **compromesso** — garanzie più forti (majority) sono più sicure e coerenti ma più lente, mentre quelle più deboli sono più veloci ma rischiano perdita di dati o letture incoerenti — e scegliere in base alla criticità dei dati (forte per dati importanti, più veloce per dati meno critici) è il giudizio chiave.

È anche rilevante che leggere dai secondari aggiunge considerazioni di eventual-consistency (letture non aggiornate).

Poiché la consistenza e la durabilità dei dati sono critiche (e il livello giusto dipende dai dati), e poiché write/read concern sono come calibri queste garanzie rispetto alla performance nell'architettura distribuita (replica set) di MongoDB, comprenderle — i livelli di durabilità/consistenza, il compromesso di performance, e scegliere appropriatamente — è una conoscenza importante a livello senior per costruire applicazioni MongoDB distribuite corrette, un argomento che dimostra comprensione dei compromessi di consistenza dei sistemi distribuiti che è particolarmente importante per applicazioni dove la perdita di dati o l'incoerenza sarebbero costose.