Strong Consistency, o Consistencia Fuerte, es el modelo de consistencia más estricto en sistemas distribuidos. Garantiza que una vez que una operación de escritura (write) se ha completado y confirmado, cualquier operación de lectura (read) subsiguiente en cualquier réplica del sistema devolverá el valor más reciente de los datos. Esto crea la ilusión de que el sistema es un único nodo monolítico, eliminando cualquier ambigüedad sobre el estado de los datos en un momento dado. Se logra típicamente a través de mecanismos que bloquean o coordinan las escrituras y lecturas entre todas las réplicas antes de confirmar una operación, asegurando que no haya lecturas "stale" o desactualizadas.
En el mundo real, Strong Consistency es fundamental para sistemas donde la integridad de los datos es primordial y no se pueden tolerar lecturas desactualizadas. Bases de datos relacionales tradicionales (como PostgreSQL o MySQL) en configuraciones de un solo nodo o con replicación síncrona a menudo exhiben Strong Consistency. En entornos distribuidos, sistemas como Google Spanner están diseñados para ofrecer Strong Consistency globalmente, utilizando relojes atómicos y algoritmos de consenso como Paxos o Raft para coordinar transacciones distribuidas. Apache ZooKeeper y etcd, utilizados para la coordinación de servicios y el almacenamiento de configuración, también proporcionan Strong Consistency para sus operaciones, siendo críticos para la fiabilidad de muchos sistemas distribuidos.
Para un Arquitecto de Sistemas, la elección de Strong Consistency implica un trade-off significativo. Si bien proporciona la máxima garantía de integridad de datos y simplifica la lógica de la aplicación al eliminar la necesidad de manejar inconsistencias, a menudo tiene un costo en términos de disponibilidad (Availability) y rendimiento (Performance). Lograr Strong Consistency en un sistema distribuido generalmente requiere coordinación entre nodos, lo que introduce latencia adicional y puede reducir la disponibilidad durante fallos de red o de nodos (violando el teorema CAP). Un arquitecto debe evaluar cuidadosamente si los requisitos de negocio para la integridad de los datos justifican esta penalización, considerando alternativas como Eventual Consistency con mecanismos de resolución de conflictos para sistemas que pueden tolerar cierta desactualización temporal a cambio de mayor disponibilidad y escalabilidad.