Consistencia Fuerte

Resumen

En un sistema con consistencia fuerte, el contrato es simple y familiar: si escribo un dato y después lo leo, obtengo el dato que escribí. Todas las réplicas acuerdan el orden de las operaciones, y una lectura nunca ve un valor anterior al de la escritura confirmada más reciente, sin importar a qué nodo le pregunte.

Este modelo sacrifica disponibilidad o latencia. Para garantizar que todas las réplicas tengan el mismo valor, el sistema debe esperar a que la escritura se confirme en un quorum de nodos antes de devolver éxito, y las lecturas también deben consultar un quorum. Si la red se parte y no se puede alcanzar el quorum, el sistema deja de responder —elige CP del teorema CAP—.

La consistencia fuerte es el modelo por defecto de las bases de datos relacionales tradicionales —una sola máquina es consistente por definición— y de sistemas como etcd, Zookeeper, y Spanner.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

Un pizarrón en una sala de reuniones. Si alguien escribe «ventas: $10 000» en el pizarrón, cualquier persona que entre a la sala después ve ese número. No hay posibilidad de que alguien vea un valor viejo porque «su copia del pizarrón no se actualizó». La consistencia fuerte es ese pizarrón único. La consistencia eventual son copias del pizarrón distribuidas en distintas salas que se actualizan cada tanto.

Uso práctico

• ✅ Coordinación: líderes de cluster, locks distribuidos, configuraciones globales —etcd, Zookeeper, Consul—.
• ✅ Sistemas financieros: transferencias, saldos que no pueden estar desactualizados.
• ❌ Alta latencia geográfica: confirmar escrituras en quorum con nodos en distintos continentes agrega decenas de milisegundos.

La mayoría de las bases de datos distribuidas no son fuertemente consistentes por defecto, pero ofrecen modos de consistencia fuerte por operación —DynamoDB strongly consistent reads, Cassandra QUORUM con read + write > replication factor—.

Ejemplo trabajado: leader election con etcd

Tres instancias de un scheduler compiten por ser el líder para evitar procesar los mismos jobs dos veces. Usan etcd —consistencia fuerte vía Raft— para adquirir un lock distribuido. La instancia A crea una key con TTL de 30 segundos y un valor que la identifica como líder. Las instancias B y C hacen watch sobre esa key. Si A falla y no renueva el TTL, etcd elimina la key y notifica a B y C. B adquiere el lock primero y se convierte en el nuevo líder. En ningún momento hay dos líderes —la consistencia fuerte lo garantiza—.

Evidencia

• Wikipedia, CAP theorem explica la consistencia fuerte en el contexto del teorema CAP y los mecanismos de quorum que la implementan (Paxos, Raft).