Modelos de consistencia

Consistencia describe qué valores y en qué orden ven los lectores en los cambios competitivos. La elección correcta del modelo es el equilibrio entre el rigor de los invariantes, la latencia, la disponibilidad y el coste (PACELC). A continuación, un manual práctico sobre modelos y sus aplicaciones.

1) Modelos «rigurosos»

Linearizable (lineabilidad, Strong)

El comportamiento es como si todas las operaciones se realizaran instantáneamente en un solo orden, respetando el tiempo real.
Pros: modelo mental simple, seguro para dinero y singularidades.
Contras: quórum/líder → crecimiento p95/p99, especialmente interregional.
Yuzkeys: balances, inventario con límites estrictos, nombres/claves únicos.

Sequential consistency

Todos los flujos ven el mismo orden de operaciones, pero el orden real-tiempo no es obligatorio. Un poco más débil que el linearizable, rara vez se expone directamente en los productos.

Serializable (serializabilidad transaccional)

Es equivalente a algún orden secuencial de transacciones (en lugar de operaciones individuales).
Ventajas: corrección de invariantes complejos a nivel de consulta/tabla.
Contras: más caro (bloqueos/versionamiento/validación de conflictos).
Yuzkeys: finoperaciones complejas, recuentos consistentes, inventario.

Snapshot Isolation (SI)

Cada transacción lee una instantánea inmutable en el tiempo; las entradas entran en conflicto por «las mismas líneas», pero es posible escribir skew.
Ventajas: lectura rápida sin bloqueos, informes estables.
Contras: no serializable, trampa write skew (ejemplo: médicos de turno).
Yuzkeys: análisis, informes, la mayoría de CRUD sin invariantes duros.

2) Por-sesión y garantías causales

Read-Your-Writes (RYW)

El cliente, después de su escritura, siempre la ve en lecturas posteriores.
Pros: buen UX (forma → confirmación).
Contras: garantía local, no global.

Monotonic Reads / Writes

Las lecturas no se «retrotraen» hacia atrás; los registros de un cliente se aplican en el mismo orden en que se enviaron.

Consistencia causal

Si la operación depende de otra (A → B), todos verán A antes de B.
Pros: intuitivamente para los amigos, comentarios.
Contras: más difícil de enrutar y marcas de causalidad (relojes vectoriales).
Yuzkeys: comunicaciones, edición conjunta, cintas de eventos.

3) Modelos débiles e híbridos

Bounded Staleness

Las lecturas no pueden retrasarse más que Δ t o N versiones.
Pros: UX predecible, buen compromiso interregional.
Contras: no protege contra conflictos de escritura.

Eventual Consistency

Con el tiempo, todas las copias convergen; el orden y el retraso no están garantizados.
Ventajas: latencia/costo mínimo, alta disponibilidad (AP).
Contras: necesita un merge explícito (CRDT/reglas de dominio).
Yuzkeys: cachés, fides, métricas, likes, nen referencias críticas.

4) Anomalías típicas y lo que significan

Dirty Read: lectura de datos no asimétricos.
Lectura no repetible: la misma lectura dentro de una transacción da valores diferentes.
Phantom: cuando se vuelve a solicitar, aparece/desaparece una cadena que encaja con el predicado.
Escritura Skew (bajo SI): dos transacciones leen un invariante intersectorial y escriben diferentes líneas, violando la condición «en suma debe ser ≥ 1».
Actualización perdida: la entrada «frota» los cambios de la competencia.

5) Quórum y niveles de lectura/escritura

Muchos almacenes permiten especificar niveles de 'R '/' W' (número de réplicas para leer/escribir).

El quórum (R + W> N) da «intersección» y fuertes garantías de las lecturas de la última escritura.
W = 1, R = 1 → baja latencia, pero los datos antiguos son posibles.
Afinación: las operaciones críticas son de alto 'W' (o líder), el resto son de bajo 'R' por velocidad.
Read-repair/Hinted handoff ayuda a alcanzar la consistencia en el fondo.

6) Horas y orden: cómo «entendemos» la causalidad

Lamport clocks: orden parcial de eventos.
Vector clocks: fijan la causalidad, permiten la detección de conflictos.
Aproximaciones Hybrid/TrueTime: limitan la dispersión de horas en el clúster para organizar transacciones y bound-staleness.
Versioning: 'version/ts + actor' para merge; en CRDT, grupos semi cerrados (conmutación/idempotencia).

7) CRDT y dominio merge

Los CRDT (tipos de datos convergentes/replicables) garantizan una convergencia sin coordinación: G-Counter, OR-Set, LWW-Register, Map, opciones de texto OT/WOOT.
Cuando es útil: me gusta, muchas etiquetas, cestas, documentos.
Limitaciones: pensar en una semántica correcta de «fusión» para una entidad de dominio específica.

8) Comunicación con CAP/PACELC

Modelos rigurosos (Linearizable/Serializable) en multi-región → CP con aumento de latencia (PACELC: seleccionamos C y pagamos L).
Modelos débiles/híbridos → AP y/o baja L, pero necesita merge/conflicto-resolve.
Híbrido: núcleo CP para invariantes + proyección AP/caché de lectura.

9) Selección de modelo: lista de cheques

1. Invariantes: ¿Qué no se puede violar? (singularidad, equilibrio, límites).
2. Regionalidad: ¿dónde se ejecutan las escrituras/lecturas? (local/global).
3. SLO por latencia: p95/p99 para rutas críticas?
4. El precio de la coordinación: ¿están dispuestos a pagar quórums interregionales?
5. Conflictos: ¿hay un merge determinista o necesita un coordinador?
6. Expectativas UX: ¿Son importantes RYW/monotonic/causal para el cliente?
7. Observabilidad: ¿Cuál es la medida del valor/conflicto/grado de obsolescencia?
8. Folbacks: ¿qué sucede cuando se divide una red (P)? ¿read-only/local/cola?

10) Recetas rápidas

Pago/saldo: Linearizable/Serializable, líder + quórum, tiempos cortos; lecturas de RYW.
Perfiles/feed: Causal/Bounded staleness + caché; CRDT para likes/contadores; RYW para el autor.
Búsqueda/análisis: SI/Read Committed, proyecciones asíncronas, eventual para índices.
SaaS Global: Geo-partitioning; «registros domésticos» - CP, informes/directorios - AP.
Edición conjunta: causal/eventual + CRDT/OT; guardar la «historia».

11) Observabilidad de la coherencia

Lag métricas: 'replication _ lag', 'staleness _ age _ ms' (p50/p95/p99).
Conflictividad: proporción de conflictos, tiempo medio de resolución.
Quórums: el éxito de los quórums 'R/W', los timautas de las rutas interregionales.
Garantías del cliente: RYW/monotonic - etiquetas de trade por sesión.

12) Errores típicos

Exigir a Strong «en todas partes» sin una base comercial → una explosión de latencia y valor.
Dual-write a diferentes regiones sin sagas/CRDT → fantasmas y pérdida de invariantes.
Ignorar RYW/montonicidad en UX → «desaparecer» los datos recién enviados.
No rastrear la obsolescencia de cachés/proyecciones → discrepancias «eternas».
Un merge mal pensado → pérdidas/tomas inesperadas de valores.

13) Mini-referencia de arquitectura

Write-core (CP): líder, registros de quórum, SLO y timeouts, revistas.
Plano de lectura (AP): vistas materializadas, cachés TTL, reparación de lectura.
Cliente: sticky-session/garantía de sesión (RYW/monotonic), etiquetas de versión.
Motor de conflicto: reglas de dominio/CRDT, cola de resolución manual.
Monitoreo: lagunas, conflictos, fracciones de lecturas obsoletas.

El modelo de consistencia es un contrato de ingeniería entre datos, latencia y disponibilidad. Comience con invariantes y SLO, elija estrictamente donde desee y más débil donde pueda, sin olvidar las garantías del cliente, quórum, reloj y observabilidad. Una combinación competente de modelos da escala, previsibilidad y resiliencia - sin sacrificar la verdad empresarial y la confianza del usuario.