Consistencia fuerte: cuando se necesita

Strong Consistency (lineabilidad) es un modelo en el que todas las operaciones se ven como si se ejecutaran instantánea y secuencialmente en un único orden global alineado con el tiempo real. El usuario leerá el último valor confirmado y los dos clientes paralelos no se «sobrepasarán» entre sí lógicamente.

La coherencia estricta proporciona un modelo mental simple y protege invariantes rígidos, pero requiere coordinación (quórum/líder), lo que aumenta la latencia y la sensibilidad a las divisiones de red.

1) Cuando Strong - obligatorio

Finanzas y cálculos

Balances y descargas: «doble desperdicio» no es válido.
Transferencias y facturas mutuas: no se puede realizar la misma cantidad dos veces.

Inventario y límites

Saldo de la mercancía/espacio en el hotel/entradas: no se puede dejar en valores negativos.
Límites de operaciones por unidad de tiempo (límites de crédito, APIs).

Singularidad e integridad

Lógicos/identificadores/reglas de deduplicación únicos.
Invariantes a nivel de dominio: «≥1 médico debe estar de servicio en la unidad», «no puede haber> N tareas activas en la cola».

Auditorías y registros inmutables

Acontecimientos que sirven como fuente jurídica de la verdad: el orden y la plenitud son críticos.

Si el incumplimiento del invariante conlleva un riesgo empresarial inaceptable (pérdida de dinero, sanciones, pérdida de confianza) - elija el Consistorio Strong.

2) Qué es exactamente «riguroso»

Linearizabilidad (nivel operativo): la lectura ve la última escritura exitosa; los tiempos son respetados.
Serializable (nivel transaccional): el resultado es equivalente a realizar transacciones en serie (puede ser strong, pero a veces implementado sin un orden de tiempo real rígido).
Diferencia importante: Serializable protege contra anomalías en el nivel de transacción (phantom/write-skew), mientras que Linearizable protege contra la momentalidad y el orden de las operaciones individuales. A menudo se necesitan ambas propiedades (por ejemplo, dinero en un registro de eventos BD +).

3) Precio de rigor: PACELC y CAP

PACELC: al dividir la red (P) hay que elegir C (rigor) o A (accesibilidad). Strong → CP: es mejor rechazar o bloquear que romper el invariante. Cuando no hay separación (EL), pagamos L - por coordinación/quórum crece p95/p99.
Práctica: strong para el «núcleo de invariantes», alrededor - proyecciones rápidas/caché con eventual para no sufrir UX.

4) Cómo se logra la Consistencia Fuerte

Liderazgo y quórums

El único líder acepta los registros; lecturas - por líder o por quórum de réplicas.
El quórum 'W' para escribir y 'R' para leer con 'R + W> N' aumenta las posibilidades de leer' último '.

Algoritmos de

Raft/Paxos: registro de replicación, confirmaciones mayoritarias, término/índices.
Replicación sincrónica: el registro sólo se confirma después de la persistencia en el quórum.

Horas y orden

TrueTime/Hybrid Logical Clocks (HLC): limitación del reloj raso para la serialización global segura.
Fence-tokens/versioning: protección contra líderes «matutinos» y split-breine.

Aislamiento de transacciones

Serializable (SI + verificación de conflictos/loki por predicados): protección contra phantom/write-skew.
Strict-serializable: serializabilidad + lineabilidad con respecto al tiempo real.

5) Multi-región: opciones y compromisos

Global Leader (CP)

Los registros pasan por una región líder; lecturas: cachés/proyecciones locales o a través de un líder.
Pros: modelo simple. Contras: p95/RTT al líder, con P - bloquear registros.

Líderes regionales + quórum sincrónico

Quórum georasshireno de varias regiones; cada registro espera confirmaciones> 50%.
Pros: sin un solo «cuello estrecho», alta resistencia. Contras: latencia intercontinental.

Geo-partitioning

Datos «domiciliarios» para la región (tenant/jurisdicción); operaciones globales - a través de sagas/agregados.
Ventajas: Latencias bajas para registros locales. Contras: planificación de límites de datos.

6) Configuración de R/W y lecturas

Entradas: 'W = majority' es el estándar para strong.

• «Lo más fresco» es 'R = majority' o una lectura del líder.
• Para reducir L es «stale-ok» leer a partir de réplicas para pantallas menores (con marcado explícito en UX).
• Read-repair/lease read: optimizaciones sin perder rigor en los alquileres cortos del líder.

7) Rendimiento y UX

Latencia: enfoca la RTT entre el cliente y el líder/quórum (interregional cientos de ms).
Patrón «write-strong, read-fast»: strong en escritura + caché/proyección en lecturas, con RYW para el autor.
Batch/packs: agrupa los registros, pero observa la latencia de la cola.
Contornos de degradación: en un incidente - sólo lectura, estados honestos, prohibición de mutaciones peligrosas.

8) Observabilidad de la vía strict

Métricas

p50/p95/p99 latency: quórum de escritura, quórum de lectura, lecturas de liderazgo.
Éxito de quórum, repeticiones/retrocesos, cambios de líder.
Maga de replicación (se espera que sea pequeña, pero es obligatorio monitorizar).
Proporción de lecturas «stale» (si están habilitadas).

Spany: «aceptación por parte del líder», «replicación», «commit quórum».
Теги: `term`, `leader_id`, `quorum_size`, `region`.

Alertas

Crecimiento p95/p99, reelección frecuente del líder, quórum-timeouts, split-brain indicadores.

9) Pruebas y caos

Jepsen-similares: particiones de red, retrasos, drops, clock-skew.
Seguridad-invariantes: imposibilidad de doble gasto/saldos negativos/doble reserva.
Liderazgo: rechazo del líder, reelección bajo carga de trabajo, fence-tokens.
Consistencia de lectura: leer inmediatamente después de escribir debe ver «nuevo» (RYW/linearizable read).

10) Playbucks de incidentes

Pérdida de quórum: cambiar a read-only, alertar a los clientes, dirigir la entrada a la región «home» si hay geo-partitioning.
El crecimiento de la latencia es interregional: reducir temporalmente el volumen de registros rigurosos (migración de parte de los flujos en cola/proyección), localizar el tráfico.
Líder de bandera: aumentar el tiempo de elección, comprobar redes/horas de deriva/pausas GC.
Split-brain: habilita los tokens de fence/lease-check, detiene los líderes antiguos a nivel de operador.

11) Errores típicos

Exigir Strong «en todas partes»: una explosión de latencia y costo en lugar de enfocarse en invariantes.
Tratar de ser CA con divisiones reales: en el momento P, el sistema todavía toma decisiones, a menudo implícitas.
Dual-write a diferentes regiones sin sagas/coordinador: fantasmas y pérdida de invariantes.
Ausencia de RYW: el usuario no ve su entidad recién grabada - una caída en la confianza.
Ignorando el reloj: sin HLC/TrueTime-bordes, es fácil obtener tiempo de «salto» y carreras.
No hay un plan de degradación: con P comienzan los fallos parciales caóticos.

12) Soluciones rápidas (recetas)

Pagos/balances: leader + majority-quórum; transacciones strict-serializables; temporizadores cortos, fallo duro bajo P.
Reservas (asientos/ranuras): write-strong a través del líder, lecturas - caché con RYW; Reservas TTL + TCC.
SaaS global: geo-partition por 'tenant/region'; operaciones estrictas en la región del hogar, informes/búsqueda - a través de proyecciones.
Auditoría/registro: registro app-only CP; las lecturas pueden ser cacheadas, pero verificadas con puntos de control.

13) Lista de verificación antes de la venta

• Se han dado de alta invariantes que requieren strong; el resto está en AR/proyección.
• Modo seleccionado: líder único/quórum interregional/geo-partition.
• Configurado por 'W = majority', 'R = leader' majority 'para rutas críticas.
• Provistos de RYW/monotonic para UX; las lecturas «stale-ok» están marcadas explícitamente.
• Se incluyen métricas de quórum, lags, latencias; alertas a p95/p99 y reelección.
• Hay un plan degrade: sólo lectura, desconexión de mutaciones peligrosas, colas para «después de la tormenta».
• Pruebas de caos: divisiones, clock-skew, fracaso del líder; safety-invariantes verificados.
• Documentación de contratos: lo estrictamente, lo que «puede quedar rezagado», comunicación para el producto/soporte.

La Consistencia Fuerte es una herramienta para defender la verdad donde el error es inaceptable. Aplíquelo puntualmente alrededor de invariantes duros, pagando conscientemente por la coordinación de latencia y disponibilidad en tormentas. Combine: El núcleo CP para crítica, lectura AP y proyección para velocidad. Con la telemetría correcta, la degradación y las pruebas, usted mantendrá tanto la corrección como la experiencia del usuario.