Consistency Models

Consistency Models

Every distributed system makes a promise about what a client will read after a write. That promise is called a consistency model. Choosing the wrong model is one of the most common sources of subtle, hard-to-reproduce bugs in production systems — the kind that only appear under network partition or when two data-centres are talking to each other at 3 AM.

This lesson covers the four models you will encounter in every serious system design conversation: strong consistency, eventual consistency, causal consistency, and read-your-writes consistency. We will look at what each guarantees, what it costs, and where each one appears in real systems you already use.

Strong Consistency (Linearizability)

A system is strongly consistent — more precisely, linearizable — when every read returns the most recently committed write, and all operations appear to happen instantaneously at a single point in global time. From the outside, the distributed system behaves as if it were a single node with a single copy of the data.

Concrete guarantee: If client A writes x = 5 and the write is acknowledged, then any subsequent read by any client anywhere in the cluster will return 5, never an older value.

Real-world examples:

• Google Spanner (TrueTime) — global SQL with external consistency
• etcd and ZooKeeper — used as cluster coordination services precisely because of their linearizable writes
• Single-node databases (PostgreSQL on one server) — trivially linearizable

Cost: Achieving linearizability across data-centres requires a synchronous round-trip for every write — every node (or quorum) must agree before the write is acknowledged. At speed-of-light distances between continents, that round-trip is 60–150 ms. Under network partition, strong-consistency systems must reject writes or go read-only rather than serve stale data (the CP side of CAP — covered in the next lesson).

Eventual Consistency

At the opposite end of the spectrum sits eventual consistency: if no new updates are made to a data item, eventually all replicas will converge to the same value. There is no guaranteed time bound, and a client may read stale data at any moment.

Concrete guarantee: If client A writes x = 5 and then client B reads immediately from a different replica, B might see the old value (x = 3). After propagation completes — typically milliseconds in practice, but theoretically unbounded — every replica will return 5.

Real-world examples:

• Amazon DynamoDB (default) — writes acknowledged after one region, async propagation
• Apache Cassandra (ONE consistency level) — tunable, but default is eventual
• DNS — a TXT record update may not be visible everywhere for up to 48 hours
• Social-media "like" counts — seeing 1,421 vs 1,423 for a few seconds is acceptable

Trade-off: Eventual consistency enables very high availability and very low write latency (no synchronous round-trip) but demands that the application layer tolerate or reconcile conflicts when two replicas diverge. Shopping carts, view counters, and DNS are canonical use-cases where the trade-off is acceptable. Bank balances are not.

Causal Consistency

Causal consistency is a middle ground that preserves the cause-and-effect relationship between operations. If operation B causally depends on operation A (e.g., a reply depends on a post), then every client that sees B must also have seen A first. Operations with no causal relationship may be observed in any order.

Why it matters — the comment example: Imagine a social platform. User A posts "I resigned today." User B replies "Congratulations!" If the system delivers B's reply to User C without delivering A's original post first, User C is confused. Causal consistency prevents this: the reply will never arrive before the post it replies to.

How it is implemented: Databases track causal dependencies using vector clocks or version vectors. Each write carries a metadata token. When a node receives a read or write, it checks that all causally prior writes are already applied before serving the request.

Real-world examples:

• MongoDB causally consistent sessions — introduced in 4.0, ensures read-your-writes within a session
• Amazon DynamoDB conditional writes with version checks
• Collaborative editing systems (Google Docs uses a variant for operational transforms)

Cost: Causal consistency is strictly weaker than strong consistency (not all reads are linearizable) but strictly stronger than eventual consistency (causally related reads are ordered). It requires vector clocks and adds some overhead, but avoids the cross-datacenter synchronous round-trip that linearizability demands.

Read-Your-Writes Consistency

Read-your-writes (also called read-your-own-writes) is a session-scoped guarantee: after a client writes a value, that same client will always read back at least that version — never an older one. Other clients may still see stale data.

This is a weaker but extremely practical model. It addresses the most frustrating user-facing inconsistency: you submit a form, the page refreshes, and your change has disappeared. That is a read-your-writes violation.

Concrete implementation strategies:

• Sticky sessions: Route all requests from the same client to the same replica. Simple, but creates hot spots and fails if that replica goes down.
• Read from primary after a write: For a configurable time window (e.g., 60 seconds after the last write), direct that user's reads to the primary. After the window expires, replica reads resume.
• Write timestamp propagation: The write returns a replication token (a timestamp or LSN). The client passes this token on subsequent reads; any replica that has not yet applied that write is skipped.

Real-world examples:

• Twitter timeline — your own tweets appear immediately in your timeline (read-your-writes), but the global feed may lag slightly
• AWS DynamoDB Strongly Consistent Reads on demand — a per-request flag that pays extra RCUs to guarantee read-your-writes
• PostgreSQL synchronous_commit = local with application-level routing

Choosing the Right Model

The following questions cut through most decision ambiguity:

1. Can users tolerate reading stale data? A "like" count that is off by 5 for a second: yes. A bank balance that is off by $200: absolutely not.
2. Are operations causally related? A threaded discussion, a collaborative document, or an order-fulfilment workflow all have strong causal dependencies. Use causal consistency or stronger.
3. Is the write the end of the interaction or the start of a session? If users immediately see what they just wrote (profile updates, settings changes), you need at minimum read-your-writes.
4. What are the geo-distribution requirements? If the system spans continents and must serve sub-50 ms reads globally, strong consistency is impractical. Eventual or causal consistency with intelligent routing is the only viable path.

Understanding these four models deeply — what each guarantees, what it costs, and where it breaks — is the foundation for every lesson in this tutorial. We will reference this vocabulary constantly as we explore replication strategies, consensus algorithms, and distributed transactions.