Consistency models

"Consistent" means different things in different contexts. In distributed systems, a consistency model defines which values a read may return given the writes that happened. From strongest to weakest:

• Linearizability (strong consistency): the system behaves as if there were one copy, and every operation takes effect atomically at some instant between its start and end. Once a write completes, every later read sees it. Needed for locks, leader election, unique usernames. Requires coordination (consensus such as Raft or Paxos), so it costs latency.
• Sequential consistency: all clients see operations in the same order, consistent with each client's own order, but not necessarily real-time order.
• Causal consistency: operations that are causally related (a reply after the message it answers) are seen in that order everywhere; unrelated ones may be seen in different orders. Achievable while staying available during partitions.
• Eventual consistency: if writes stop, replicas eventually converge. Says nothing about what you read meanwhile.

Between these sit session guarantees that fix the most visible problems cheaply: read-your-writes, monotonic reads (never see time go backwards), monotonic writes and writes-follow-reads.

Don't confuse this with serializability, which is about transactions over multiple objects (isolation), whereas linearizability is about single-object recency. Strict serializability combines both, and is what systems like Spanner offer.