¿Cómo afectan la intención de escritura y la intención de lectura a la consistencia?

Question

Accepted Answer

**Write concern** y **read concern** controlan las garantías de consistencia y durabilidad en MongoDB (en conjuntos de réplicas) — realizando un balance entre **rendimiento** y **seguridad/consistencia**. Te permiten ajustar la fuerza con la que se confirman las escrituras y qué tan consistentes son las lecturas, según las necesidades de los datos.

## Write concern — durabilidad de escrituras

```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 la durabilidad: `w: "majority"` asegura que la escritura se replica a la mayoría (sobrevive a un failover sin pérdida), pero es más lenta; `w: 1` es más rápida pero una escritura podría perderse si el primario falla antes de la replicación.

## Read concern — consistencia de lecturas

```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 qué datos ven las lecturas: `majority` devuelve solo datos confirmados por mayoría (no se revierte — consistente), versus `local` (los datos locales más recientes, posiblemente aún no confirmados por mayoría).

## El balance consistencia vs rendimiento

```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 qué es importante

Entender write concern y read concern es importante para **gestionar el balance consistencia-vs-rendimiento** en conjuntos de réplicas de MongoDB, por lo que es conocimiento valioso a nivel senior para construir aplicaciones MongoDB distribuidas correctas y ajustadas apropiadamente.

Estas configuraciones controlan las garantías de consistencia y durabilidad de MongoDB, y entenderlas es necesario para asegurar que los datos se manejen con el nivel adecuado de seguridad según su importancia. **Write concern** es particularmente importante para **durabilidad**: `w: "majority"` asegura que una escritura se replica a la mayoría de nodos (sobrevive failover del primario sin pérdida de datos — crítico para datos importantes como pagos u órdenes), mientras que `w: 1` es más rápido pero riesga perder una escritura si el primario falla antes de la replicación — un balance consecuente donde elegir incorrectamente podría significar pérdida silenciosa de datos en failover. **Read concern** controla **consistencia de lectura**: `majority` devuelve solo datos confirmados por mayoría (consistente, no se revierte) versus `local` (los datos más recientes, posiblemente aún no duraderos y sujetos a reversión) — afectando si las lecturas podrían ver datos que después desaparecen.

Entender el **balance** — garantías más fuertes (mayoría) son más seguras y consistentes pero más lentas, mientras que las más débiles son más rápidas pero riesgan pérdida de datos o lecturas inconsistentes — y elegir basándose en la criticidad de los datos (fuerte para datos importantes, más rápido para menos críticos) es el juicio clave.

También relevante es que leer de secundarios añade consideraciones de eventual-consistency (lecturas antiguas).

Ya que la consistencia y durabilidad de datos son críticas (y el nivel correcto depende de los datos), y ya que write/read concern es cómo ajustas estas garantías contra rendimiento en la arquitectura distribuida de MongoDB (conjunto de réplicas), entenderlas — los niveles de durabilidad/consistencia, el balance de rendimiento, y elegir apropiadamente — es conocimiento importante a nivel senior para construir aplicaciones MongoDB distribuidas correctas, un tema que demuestra entendimiento de los balances de consistencia en sistemas distribuidos que es especialmente importante para aplicaciones donde la pérdida o inconsistencia de datos sería costosa.