Consistencia eventual en la práctica

La consistencia eventual (EC) es un modelo en el que las copias de los datos pueden divergir temporalmente, pero convergen con el tiempo sin coordinación global. Esta es la clave de alta disponibilidad (AP por CAP) y baja latencia (PACELC) si se definen correctamente los invariantes, las reglas del merge y las garantías del cliente.

1) Cuándo elegir EC (y cuándo - no)

• Fides, perfiles, likes/contadores, directorios/búsquedas, vistas en caché.
• Sistemas globales con registros locales e invariantes blandos.
• Proyecciones (CQRS) donde la fuente de la verdad es un núcleo estricto y las lecturas son asíncronas.

• Invariantes duros: dinero, singularidad, límites, inventario de «no salir en negativo». Allí - CDR/EC más fuerte, sagas/TSS.

2) Diseño de datos bajo CE: conflictos y su resolución

Principio: cada entrada lleva metadatos de versión y una función de fusión determinista.

Marcas de tiempo/versionamiento: 'versión', 'ts',' actor '.
Relojes vectoriales: fijan la causalidad, permiten entender «paralelos conflictivos».

• LWW (Last-Write-Wins): simple y rápido, pero puede perder «sentido».
• CRDT: estructuras conmutativas/idempotentes, garantizan la convergencia.
• Dominio merge: función empresarial (por ejemplo, combinar listas sin tomas, sumar contadores, «email más nuevo + combinación de etiquetas»).

• Contadores → G-Counter/PN-Counter.
• Múltiples → OR-Set (desinstalaciones sin «verter»).
• Registros → LWW-Register (con precaución a las «pérdidas»).
• Mapas/documentos → Mapa de CRDTs.
• Edición conjunta → texto CRDT/OT.

3) Replicación y anti-entropía

Gossip/anti-entropy: intercambio periódico de estados/hash entre nodos.
Hinted handoff: «depositar» temporalmente un registro para un nodo inaccesible.
Read repair: al leer, descubrieron la desajuste - apretaron las versiones nuevas.
Paquetes de cambio (deltas): perseguimos delta en lugar de tomas completas.
Quórums R/W: sintonizar 'R', 'W', 'N' bajo un compromiso de velocidad y frescura (por ejemplo,' R + W> N' más cerca de strong en la «última grabación»).

4) Garantía del cliente sobre EC

Read-Your-Writes (RYW): el autor, después de su grabación, la ve (sticky-session/versión de etiquetado).
Monotonic Reads: no «retroceder» el cliente a un valor más antiguo (almacenar watermark de la última versión).
Consistencia causal: mantenemos la causalidad dentro de la sesión/flujo de acción (etiquetas vectoriales en encabezados/fichas).
Bounded Staleness: garantía de «no más de Δ versiones t/N» para pantallas críticas de UX.

5) Patrones UX para EC

Apdates optimistas: reflejamos instantáneamente la acción, marcando la «sincronización».
Etiquetado de frescura: etiqueta «Actualizado X segundos atrás», botón «Actualizar».
Conflicto-IU: para colisiones raras - «mostrar ambas versiones y seleccionar/combinar».
Skeleton/placeholder + soft refresh: no bloquear la IU por la espera de quórums globales.

6) Plantillas arquitectónicas

6. 1 proyección CQRS +

Núcleo de escritura (CP): invariantes estrictos.
Plano de lectura (EC): proyecciones asíncronas, índices, cachés; Vamos a admitir que lo hagamos.

6. 2 Multi-región AP

Los registros son localmente rápidos, la replicación es asíncrona.
Geo-partitioning: los datos «viven» más cerca del usuario; región cruzada - agregados.
Las funciones CRDT/merge alivian el dolor de los conflictos.

6. 3 Configuración de quórum

yaml consistency:
replicas: 3 # N write_quorum: 2 # W read_quorum: 2 # R => R + W> N, closer to freshness on "last record"
read_repair: true hinted_handoff: true

7) Políticas de versificación y merge (ejemplo)

yaml entity: "profile"
versioning:
clock: "vector"    # или "hybrid_time"
fields:
name:   { merge: "lww" }
emails:  { merge: "set_union" }   # OR-Set tags:   { merge: "or_set" }
likes:   { merge: "pn_counter" }
conflict_ui:
enabled: true show_diff_for: ["name"]
auto_merge_for: ["emails","tags","likes"]

8) Observabilidad EC: qué medir

Staleness Age (p50/p95/p99): 'now − data_version_ts' o' número de versiones atrasadas '.
Registro de replicación: retraso en la entrega entre regiones/nodos.
Tasa de conflicto: proporción de apdates paralelos, distribución por tipo.
Read-Repair Nota/Latency: con qué frecuencia y qué rapidez «tratamos» cuando leemos.
Tiempo de convergencia: tiempo antes de la convergencia después de un estallido de registros/fallo del nodo.
SLO semántico: "95% de los perfiles no son mayores de 2s", "99% del feed converge <10s'.

9) Runbook 'e incidentes

1. El crecimiento del lag es interregional: reducir 'write fan-out', incluir una lectura-reparación agresiva, atornillar a los escritores pesados.

2. Estallido de conflictos: habilitar temporalmente una regla más «estricta» (por ejemplo, causal/RYW), restringir los updates competitivos en las llaves calientes.

3. Retraso en las proyecciones: priorice las colas de replicación, reduzca temporalmente la frecuencia de los apdates no críticos.

4. Los datos se «filtraron» en una parte de los nodos: fuerza anti-entropía, rebalance de lotes, auditoría hinted handoff.

5. Análisis manual: descarga de claves de conflicto, herramienta «merge-preview», fix de batalla.

10) Prueba EC

Pruebas similares a Jepsen: particiones de red, clock-skew, regrabaciones.
Property-based: invariantes de funciones merge (conmutabilidad, idempotencia, asociatividad).
Conflictos Fuzz: apdates paralelos en una sola clave con orden de entrega variable.
«Sierras» de carga: alternancia de Bourst/Shutter para evaluar el tiempo de convergencia.
Simulaciones UX: visibilidad RYW/monotonic en escenarios típicos.

11) Multi-tenant y planes

Etiquetas 'tenant _ id/plan/región' en eventos/registros.
Fairness: límites a la replicación/repair per tenant para que el cliente «ruidoso» no aumente la staleness general.
Residencia: los datos y sus réplicas dentro de la jurisdicción; representaciones cruzadas-regionales sólo agregados.

12) Errores típicos

LWW «para todo». Pierde los cambios semánticos paralelos; utilice CRDT/dominio merge.
No hay garantías del cliente. El usuario «no ve» su propio registro → pérdida de confianza.
Falta de observabilidad de la obsolescencia. No hay métricas de staleness/lag → «degradación oculta».
Dual-write en diferentes sistemas sin merge. Los fantasmas y las discrepancias son infinitos.
Orden mundial a toda costa. Los quórums superfluos matan a p95, y los negocios tienen suficiente orden local.

13) Recetas rápidas

Fid/cinta: EC + causal/RYW para autor, CRDT para reacciones, staleness p95 ≤ 2-5s.
Perfiles/ajustes: staleness bounded (≤1 -2c), RYW, dominio merge (unión de conjuntos).
Catálogo global: geo-partition, replicación asíncrona, read-repair bajo demanda, conflictos a través de OR-Set.
Métricas/contadores: PN-Counter, consolidación en el fondo; muestra valores «aproximados» marcados.

14) Mini-referencia (esquema verbal)

Escritura-edge: registro local con versión ('vector/hybrid'), registro de eventos.
Replication: очереди + gossip/anti-entropy, hinted handoff.
Almacenamiento: partición por clave, función CRDT/merge a nivel de escritura.
Read-plane: cachés con read-repair, tokens RYW/monotonic, staleness bounded para pantallas críticas.
Observabilidad: lags/obsolescencia/conflictos, alertas por exceso de SLO de Steilness.

15) Lista de verificación antes de la venta

• Se describen claramente los invariantes y dónde se permite la EC.
• Se seleccionaron la versionación (vector/hybrid) y las funciones deterministas merge/CRDT.
• Se han implementado garantías de cliente (RYW/monotonic/causal) para UX críticos.
• Replicación personalizada, read-repair, hinted handoff; los quórums R/W están documentados.
• Métricas de staleness/lag/convergence y alertas en los umbrales p95/p99.
• Runbook 'y sobre el aumento de los conflictos/lagunas; herramientas seguras de merge manual.
• Pruebas de particiones de red, apdates paralelos y propiedad de convergencia.
• Se tienen en cuenta los límites multi-tenantes y las políticas de residencia.
• Los indicadores UX de frescura y comportamiento fallback están alineados con el producto.

La consistencia eventual no es un «compromiso en aras del compromiso», sino una herramienta de escalabilidad y disponibilidad. Si formaliza invariantes, elige funciones merge correctas (preferiblemente CRDT cuando corresponda), da garantías al cliente y mide el tiempo y el tiempo de convergencia, el sistema será rápido, sostenible y honesto, tanto para los usuarios como para las empresas.