Como write concern e read concern afetam a consistência?

Question

Accepted Answer

**Write concern** e **read concern** controlam as garantias de consistência e durabilidade no MongoDB (em replica sets) — equilibrando entre **performance** e **segurança/consistência**. Eles permitem ajustar como fortemente as escritas são confirmadas e como as leituras são consistentes, baseado nas necessidades dos dados.

## Write concern — durabilidade das escritas

```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** controla durabilidade: `w: "majority"` garante que a escrita é replicada para a maioria (sobrevivendo a failover sem perda) mas é mais lento; `w: 1` é mais rápido mas uma escrita pode ser perdida se o primário falhar antes da replicação.

## Read concern — consistência das leituras

```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** controla quais dados as leituras veem: `majority` retorna apenas dados comprometidos pela maioria (não será revertido — consistente), versus `local` (os dados locais mais recentes, possivelmente ainda não comprometidos pela maioria).

## O equilíbrio entre consistência 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).
```

## Por que isso importa

Compreender write concern e read concern é importante para **gerenciar o equilíbrio entre consistência e performance** em replica sets do MongoDB, então é conhecimento valioso de nível sênior para construir aplicações MongoDB distribuídas corretas e apropriadamente sintonizadas.

Essas configurações controlam as garantias de consistência e durabilidade do MongoDB, e compreendê-las é necessário para garantir que os dados sejam tratados com o nível correto de segurança para sua importância. **Write concern** é particularmente importante para **durabilidade**: `w: "majority"` garante que uma escrita é replicada para a maioria dos nós (sobrevivendo a failover do primário sem perda de dados — crítico para dados importantes como pagamentos ou pedidos), enquanto `w: 1` é mais rápido mas arrisca perder uma escrita se o primário falhar antes da replicação — um equilíbrio consequente onde escolher errado poderia significar perda de dados silenciosa em failover. **Read concern** controla **consistência de leitura**: `majority` retorna apenas dados comprometidos pela maioria (consistente, não será revertido) versus `local` (os dados mais recentes, possivelmente ainda não duráveis e sujeitos a reversão) — afetando se leituras podem ver dados que depois desaparecem.

Compreender o **equilíbrio** — garantias mais fortes (maioria) são mais seguras e consistentes mas mais lentas, enquanto as mais fracas são mais rápidas mas arriscam perda de dados ou leituras inconsistentes — e escolher baseado na criticidade dos dados (forte para dados importantes, mais rápido para menos críticos) é o julgamento chave.

Também relevante é que ler de secondários adiciona considerações de eventual-consistency (leituras obsoletas).

Como consistência de dados e durabilidade são críticas (e o nível correto depende dos dados), e como write/read concern são como você sintoniza essas garantias contra performance na arquitetura distribuída (replica set) do MongoDB, compreendê-los — os níveis de durabilidade/consistência, o equilíbrio de performance, e escolher apropriadamente — é conhecimento importante de nível sênior para construir aplicações MongoDB distribuídas corretas, um tópico que demonstra compreensão dos equilíbrios de consistência em sistemas distribuídos que é especialmente importante para aplicações onde perda de dados ou inconsistência seria custosa.