Un Consistency Model es un contrato formal que especifica cómo las operaciones de lectura y escritura en un sistema distribuido se ordenan y se hacen visibles para los procesos concurrentes. Determina la "frescura" y la coherencia de los datos que un cliente puede esperar ver. Modelos como Strong Consistency (ej. Atomic Consistency/Linearizability) garantizan que todas las operaciones parecen ejecutarse atómicamente en un orden global total, como si hubiera una única copia de los datos. Otros modelos, como Eventual Consistency, permiten estados inconsistentes temporales, pero garantizan que, si no hay nuevas escrituras, todas las réplicas eventualmente convergerán al mismo valor.
En el mundo real, la elección del Consistency Model es fundamental. Bases de datos relacionales tradicionales y sistemas como Apache ZooKeeper o etcd implementan Strong Consistency (a menudo Linearizability) para sus metadatos críticos, utilizando algoritmos de consenso como Paxos o Raft. Por otro lado, sistemas NoSQL como Apache Cassandra, Amazon DynamoDB y Cosmos DB (con sus niveles de consistencia configurables) suelen ofrecer Eventual Consistency o modelos intermedios como Bounded Staleness o Causal Consistency. Estos sistemas priorizan la disponibilidad y la tolerancia a particiones sobre la consistencia estricta, lo que los hace adecuados para cargas de trabajo a gran escala donde la latencia baja y la alta disponibilidad son primordiales.
Para un arquitecto, comprender los Consistency Models es crucial para diseñar sistemas distribuidos robustos y eficientes. La elección de un modelo implica un trade-off directo entre consistencia, disponibilidad y tolerancia a particiones (el teorema CAP). Un modelo de Strong Consistency simplifica la lógica de la aplicación al garantizar que los datos son siempre coherentes, pero puede introducir latencia y reducir la disponibilidad durante fallos de red o nodos. Por el contrario, modelos más relajados como Eventual Consistency ofrecen mayor disponibilidad y menor latencia, pero requieren que el arquitecto y los desarrolladores manejen la posible inconsistencia de los datos a nivel de aplicación, a menudo mediante la implementación de estrategias de resolución de conflictos o la aceptación de datos potencialmente "stale" por un período. La decisión debe alinearse con los requisitos funcionales y no funcionales del negocio, como la criticidad de los datos, las expectativas de latencia y los SLA de disponibilidad.