PAC y Compromís de Ingeniería

La PAC argumenta: en condiciones de separación de la red (Partition, P), el sistema distribuido no puede garantizar al mismo tiempo una fuerte coherencia (Consistencia, C) y disponibilidad (Availabilidad, A). Si tiene P, tiene que elegir CP o AP. En ausencia de divisiones, la restricción no es válida, pero aparecen otros compromisos - sobre todo la demora (latencia) y el costo.

La ingeniería práctica va más allá del CAP: PACELC es importante (si P - seleccionamos C o A; de lo contrario - elegir entre Latency y Consistency), modelos de coherencia, SLA/SLO, yuzkeys y riesgos empresariales.

1) Definiciones básicas (sin filosofía)

Consistencia (C): todos los clientes ven el mismo resultado «como si» las operaciones se realizaran en serie (lineabilidad/consistencia estrong).
Disponibilidad (A): cada solicitud a un nodo que no ha caído se completa con una respuesta en un tiempo razonable, incluso cuando está dividida.
Separación (P): pérdida o degradación significativa de la comunicación entre nodos/clústeres regionales; esencialmente - «inevitable» a gran escala.
PACELC: en P, seleccionamos C o A; else (cuando P no) seleccionamos L (baja latencia) o C (fuerte consistencia).

2) Imagen de selección intuitiva

CP (la consistencia es más importante): al dividir una parte de las solicitudes, rechazamos/bloqueamos para no interrumpir invariantes. Adecuado para dinero, transacciones, contabilidad de saldos.
AP (la disponibilidad es más importante): respondemos siempre, pero permitimos la descoordinación temporal, luego agarramos los conflictos (CRDT/reglas del merge). Adecuado para los medios de comunicación, contadores de me gusta, perfiles en caché.
CA (simultáneamente C y A): sólo es posible en ausencia de P - es decir, mientras la red esté sana. En la explotación real, «CA» es un estado temporal, no una propiedad de diseño.

3) PACELC: no olvidemos el retraso

• Fuerte consistencia entre regiones = quórums intercontinentales ⇒ decenas a cientos de ms a p95.
• Lecturas locales (baja L) = garantías más débiles (lectura-mis-escritos, staleness bounded, eventual).
• PACELC ayuda a explicar por qué es «rápida y rigurosamente» global - raro: la luz no es instantánea, sino que los quórums crecen con la plegabilidad de la red.

4) Modelos de consistencia (espectro rápido)

Linearizable/Strong: como si fuera un orden secuencial.
Serializable: equivale a un orden secuencial de transacciones (por encima del nivel de registros).
Read-your-writes/Monotonic reads: el cliente después de su propia entrada lee un nuevo valor.
Staleness bounded: las lecturas no son mayores que N versiones/ Δ t.
Consistencia eventual: con el tiempo, todas las copias convergen; los conflictos deben resolverse.

5) Patrones CP y AP en productos y protocolos (conceptualmente)

Enfoques CP: registros de quórum/liderazgo (Raft/Paxos), transacciones estrictas, ubicaciones de líderes globales, replicación sincrónica. Precio: falla de parte de las solicitudes en P y aumento de los retrasos.
Enfoques AP: multi-master/multi-leader, CRDT, propagación gossip, replicación asíncrona, resolución de conflictos (LWW, relojes vectoriales, funciones de mercado de dominio). El precio es la descoordinación temporal y la complejidad de las reglas de dominio.

6) Compromisos en la multi-región

Líder Global (CP): lógica simple, pero las regiones «lejanas» pagan con latencia; P - Bloqueo de registros.
Líderes locales + asinchron (AP): la escritura es rápida localmente, luego la replicación; los cambios conflictivos requieren merge.
Geo-partitioning: los datos «viven» más cerca del usuario/jurisdicción; región cruzada - sólo unidades.
Dual-write está prohibido sin sagas/CRDT: de lo contrario, se obtienen phantoms y dobles descargas.

7) Invariantes de ingeniería y soluciones de negocios

Primero invariantes: lo que nunca se puede romper (doble caudal, residuo negativo, singularidad de la llave), y lo que «sobrevive» eventual (contador de vistas, recomendaciones).

• Invariante «duro» → CP para operaciones relevantes.
• El invariante es «suave» → AP seguido de un agarre.

8) Técnicas de mitigación de compromisos

Caché y CQRS: lecturas a través de caché/proyección cercana (AP), entradas en registro estricto (CP).
RPO/RTO como lenguaje de compromiso: cuántos datos se pueden perder (RPO) y cómo recuperarse rápidamente (RTO).
ID y relojes consistentes: timestamps monótonos (aproximaciones Hybrid/TrueTime), ULID/Snowflake.
Sagi/TSS: compensación empresarial en lugar de bloqueos globales.
CRDT y Domain Merge: para colecciones, contadores, «últimas victorias».
Staleness Bounded: balance de UX y precisión.

9) Vigilancia, SLO y gestión de incidentes

SLO por latencia (p50/p95/p99) por separado para lecturas/registros y regiones.
SLO por accesibilidad, teniendo en cuenta el Feilover de la región.
Registro de replicación/conflicto: proporción de conflictos, tiempo medio de resolución.
Alertas según el signo P: un repunte de los timautas de los canales interregionales, un aumento de los errores de quórum.
Planes de Degrade: modo sólo lectura, mantenimiento local seguido de merges, desactivación de funciones «caras».

10) Check-list de selección de estrategia

1. ¿Qué invariantes no se pueden violar? ¿Qué permite el evento?
2. ¿Se necesita un registro cruzado regional con baja latencia?
3. ¿Cuáles son los SLO de destino (latencia/disponibilidad) y el costo (egress/replicación)?
4. ¿Permite el merge manual o sólo el autómata (CRDT/reglas)?
5. ¿Cuál es el perfil de fallo de la red: frecuencia, duración, blast radius?
6. ¿Existe una localización legal de los datos (residencia)?
7. ¿Qué modelo de consistencia es aceptable para cada tipo de datos/operación?
8. ¿Cómo observará: los lags, los conflictos, el estado de los quórums?
9. ¿Qué hace el sistema cuando P: bloquea, degrada, divide el tráfico?
10. ¿Qué plan de recuperación y repatriación de datos después de P?

11) Errores típicos

Persiguiendo a «CA para siempre». La primera vez, P tendrá que elegir mejor de antemano.
Multi-Master Global sin reglas de Merge. Los conflictos «se comen» los datos y la confianza.
Fuerte consistencia «en todas partes». El exceso de quórum golpea p95/p99 y el presupuesto.
Dual-write sin transacciones/sagas. Invariantes y fantasmas perdidos.
Ignorando PACELC. En tiempos de paz, la latencia sufre, en tormenta, la disponibilidad.
Cero telemetría de conflictos y lagunas. Los problemas sólo son visibles para el usuario.

12) Recetas rápidas

Pago/Saldo: Almacenamiento CP con quórum; registros sólo a través del líder; las lecturas se pueden almacenar en caché, pero en UX críticos - read-your-writes.
Contenido/feed: replicación AP + reglas CRDT/Merge; con P - servir localmente, luego agarrar.
SaaS global: geo-partitioning por 'tenant/region'; operaciones estrictas en la región «home» (CP), informes/búsqueda - a través de proyecciones asíncronas (AP).
Señal de tiempo real: Anycast/edge + bus AP; los comandos críticos pasan por un canal confirmado (CP).
Auditoría/registro: la única fuente de verdad (append-only) con garantías CP, alrededor de caché y proyección.

13) Mini-referencia de arquitectura (verbalmente)

Write-core (CP): leader + replicación de quórum, invariantes estrictos, sagas para efectos interservicios.
Leer plano (AP): vistas materializadas, cachés, índices de búsqueda, actualización asíncrona.
Geo-routing: los usuarios entran en una región «doméstica»; en P, modo local + replicación posterior.
Motor de conflicto: CRDT/reglas; registro de conflictos y medios de resolución manual.
Observabilidad: trayecto de quórum, lagi, mapa de incidentes de la red.

14) Matemáticas prácticas de la demora (evaluación simple)

Óptica ≈ 5 ms por 1000 km (RTT aún más). Los quórums intercontinentales → p95 son fáciles> 150-250 ms.
Cualquier «Strong global» para escribir es una consulta costosa. Si UX requiere <100-150 ms, piense en los efectos asíncronos locales write-home +.

15) Políticas en caso de divisiones

Ruta CP: bloquear registros fuera del quórum; incluir sólo lectura; dar estados honestos al usuario.
Ruta AP: servir localmente; etiquetar versiones; durante la restauración - merge determinista; los conflictos se elevan a la cola de discusión.

Conclusión

El PAC no es un dogma, sino un recordatorio: las divisiones de la red son inevitables y el proyecto debe elegir de antemano qué sacrificar en la tormenta -la accesibilidad o la rigurosa consistencia-. PACELC añade un eje clave de retraso en tiempo despejado. Combinar estrategias: mantener el núcleo CP donde los invariantes son sagrados y el plano AP donde la velocidad y la estabilidad son más importantes. Hipotecar la telemetría, los planes de degradación y los procesos de merge - y el sistema guardará tanto los datos como la confianza del usuario.