A consistency model is the contract a distributed datastore makes about what a read can return relative to recent writes. Because data is replicated across machines and updates take time to propagate, different systems offer different promises about when a write becomes visible. Werner Vogels lays out this spectrum in his 2008 article “Eventually Consistent,” describing the contract from the perspectives of both the storage system and the client process.
At the strong end is strong consistency, where after an update completes every subsequent access returns the updated value, as if there were a single up-to-date copy. Weak consistency makes no such promise: the system does not guarantee that subsequent reads see the latest write until some condition is met. Eventual consistency is a specific weak model in which, absent new updates, all replicas eventually converge.
Between the extremes sit client-centric variations that Vogels enumerates: causal consistency (operations related by cause are seen in order), read-your-writes (a process always sees its own updates), monotonic reads (a process never sees an older value after a newer one), monotonic writes (a process’s writes are serialized), and session consistency (read-your-writes guarantees scoped to a session). These give application designers finer control than a blunt strong-or-eventual choice.
Consistency models matter because they sit at the heart of the CAP trade-off. As Brewer’s 2012 retrospective on CAP emphasizes, the behavior a system promises during and after a network partition is essentially a choice of consistency model, and picking the right one is how designers balance correctness against availability and latency for a given workload.