Consistency Models

Pradeep P
3 days ago
3 min read

Series: Modern System Design · Layer 3 — Reliability

Layer 3 · Post 14 of 14

← Previous: CAP Theorem → Next: ACID

Layer 3 — Reliability · Post 39 of 88

Consistency models describe how stale or surprising a read is allowed to be. Strong, eventual, and everything in between are explicit product choices.

What you'll learn

Eventual vs strong vs "read your writes" — what the user can actually observe
Why replication lag (Post 34) is a consistency bug if you promised the wrong model
How to pick a model in a design interview without saying "we'll use strong consistency" for every row

The idea in one minute

A consistency model is the contract: after a write, which reads are allowed to be stale or reordered?

Write "name=Ada" on primary | +--> read replica 50 ms later: still "Bob" (eventual: allowed) +--> read primary: "Ada" (read-your-writes if you stay here) +--> every reader worldwide: "Ada" before ack (strong / linearizable: expensive)

CAP (previous) is the partition fork: error vs diverge. Consistency models are the everyday spectrum, including when the network is fine.

Layer 4's ACID is what one database node (or a transactional product) promises for transactions. This post is what distributed copies promise for reads.

Why it matters

Users do not say "eventual consistency." They say "I saved and it's gone," "the follower count jumped backward," "two tabs disagree." Those are model violations relative to what you implied in the UX.

Interviews: pick per use case. Ledger and inventory: strong or a single-primary write path. Feed counts, CDN HTML, DNS: eventual. Session after login: read-your-writes. Saying one word for the whole system is how designs get expensive or wrong.

How it works

Strong / linearizable. There is a single global order. Once a write acks, any later read (by wall clock, any client) sees it. Requires coordination (leader, quorum, Spanner-style). High latency across regions. Failures look like CAP-CP: you wait or error.

Read-your-writes. The client that wrote sees its write. Sticky sessions, read-from-primary after POST, version tokens, Cosmos "session consistency." Other users may still be stale. For "simple strong," say read the primary. Serializability is a transaction idea — Layer 4.

Monotonic reads. You never go backward (see Ada, then later Bob). A load balancer hopping to an older replica can violate this.

Eventual. If writes stop, replicas converge. Until then, you need a merge rule (LWW, counters, CRDTs). DNS, caches, CDNs (Post 8). Tunable stores (Cassandra, DynamoDB, Cosmos) let you choose per request: strong when it matters, eventual for a view count.

A simple example

Twitter-style follow button.

Follow write: must not double-follow; unique key / primary. Strong on that row.
Follower count on the profile: eventual. A few seconds late is fine. Don't read it from a replica in a way that decreases after you just followed (monotonicity), or users think the tap failed.
Your own profile right after edit: read-your-writes (primary or session).

Two checkouts that both read "1 left" and both succeed did not pick a strong enough model. That story continues in ACID.

Common mistakes

Promising strong in the UI, serving from an async replica. Post 34's stale read.

Eventual without a repair path. "We'll converge" with no anti-entropy, no idempotent replay.

One model for the whole company. Spanner-for-everything vs Redis-for-money.

Calling cache TTL a consistency model and stopping. Caches are eventual with a max staleness. Say the number. Clients roaming regions also break monotonic reads.

How this shows up in real systems

DynamoDB: eventual by default; strongly consistent as an option (single region).
S3: strong consistency for new objects (they moved the contract in 2020).
Spanner, Cosmos DB: session / bounded-staleness / strong as product knobs.
Postgres primary + replicas, Redis replica, Kafka consumer lag: you pick the model by where you read.
CDN / CloudFront: public cache = eventual with TTL.

Recap

Consistency models are what stale or reordered reads you allow.
Match UX: strong (or primary reads) for money and "I just saved"; eventual for fan-out and caches.
CAP was the partition choice. This was the daily choice. Next layer: ACID — transactions on one (logical) database.