MongoDB
Explica los niveles de read concern y qué visibilidad ofrecen sobre datos locales, mayoritarios, linealizables o snapshots en replica sets y transacciones.
Read concern define qué nivel de visibilidad exige una lectura. No decide en qué nodo se lee —eso corresponde a read preference—, sino qué estado de los datos es aceptable dentro de la topología y operación.
read preference
→ qué miembro puede atender
read concern
→ qué garantía de visibilidad exigeDevuelve los datos más recientes disponibles en el miembro que atiende la lectura. En determinadas condiciones, datos todavía no majority-committed podrían revertirse durante un failover.
Es una opción común cuando se prioriza baja coordinación y la aplicación tolera esa ventana.
Favorece disponibilidad y puede ser relevante en contextos sharded. Sus garantías y diferencias respecto a local dependen de topología; no debe elegirse únicamente por el nombre.
Devuelve datos confirmados por una mayoría de miembros con voto y aptos para permanecer tras los failovers soportados.
const document = await collection.findOne(
{ _id: orderId },
{ readConcern: { level: 'majority' } }
);No significa consultar todos los nodos ni esperar que cada réplica tenga el dato.
Busca una lectura con semántica linealizable sobre el primary para casos estrictos. Tiene restricciones, mayor coordinación y no debe ser el valor general de una API sin necesidad demostrada.
Permite una vista consistente de snapshot en contextos compatibles, especialmente transacciones y sesiones. Las operaciones ven un punto lógico coherente en lugar de mezclar versiones.
En un replica set, las operaciones avanzan hacia un punto confirmado por mayoría. Read concern majority limita la lectura a datos en ese estado.
write llega al primary
→ se replica
→ mayoría confirma
→ majority commit point avanzaReplication lag puede retrasar la visibilidad o aumentar la latencia de algunas lecturas.
Una escritura con w: 'majority' espera confirmación de mayoría. Una lectura con majority exige datos majority-committed. Son decisiones relacionadas, pero no intercambiables.
Para read-your-writes también importan:
Dentro de una session causalmente consistente, operaciones relacionadas pueden preservar garantías como read-your-writes y monotonic reads cuando se usan las opciones compatibles.
const session = client.startSession({ causalConsistency: true });
try {
await orders.updateOne(filter, update, { session });
const order = await orders.findOne(filter, { session });
} finally {
await session.endSession();
}No compartas la misma session concurrentemente entre requests.
Las transacciones suelen utilizar snapshot semantics y un write concern apropiado al commit. No cambies concerns dentro del flujo sin entender las restricciones del driver y servidor.
Una transacción larga mantiene una vista antigua y puede incrementar presión sobre storage, history store y recursos.
Leer con secondary y local puede devolver datos atrasados. majority evita leer cambios no confirmados por mayoría, pero no garantiza que el secondary esté al día con el primary.
majority committed
≠ último estado del primarylocal o lectura de secondary puede ser suficiente.
Primary, session causal y concerns apropiados pueden ser necesarios.
Snapshot, corte temporal o fuente analítica según duración.
Necesita una política más estricta y evitar secondaries atrasados.
Más garantía puede implicar coordinación, espera por replication o menor flexibilidad de routing. Sin embargo, elegir un concern débil no corrige una query lenta por índice o schema.
Mide latencia y comportamiento durante failovers, no solo en estado estable.
linearizable tiene restricciones de operación y topología.majority consulta todos los nodos;Read concern controla la visibilidad mínima de una lectura; read preference elige el miembro. majority reduce exposición a datos revertibles, snapshot conserva una vista coherente y causal sessions relacionan operaciones. La elección debe partir de la invariantes, no del nivel que suena más fuerte.
Write concern.