Consistency Patterns

Preview — 3 of 10 questions

A distributed key-value store offers three consistency modes. After writing balance = 100, a client immediately reads the value. Under which consistency model can the read return a stale value — or even fail to return the write at all?

javascript
Weak consistency:
  Write: balance = 100
  Immediate read: balance = ??? (could be 100, 80, or nothing)
  No guarantees  best-effort only
  Use case: real-time metrics, VoIP, live video streaming
  (a dropped frame or stale counter is acceptable)

Eventual consistency:
  Write: balance = 100
  Immediate read: balance = 80 (still propagating)
  Later read:     balance = 100  (all replicas converged)
  Guarantee: will converge "eventually" (milliseconds to seconds)
  Use case: DNS, email, shopping cart, social media likes

Strong consistency:
  Write: balance = 100
  Immediate read: balance = 100  (always)
  Guarantee: every read sees the most recent write or an error
  Cost: higher latency (must wait for all replicas to confirm)
  Use case: financial transactions, inventory, reservations
AWeak consistency — the system makes no guarantee that a subsequent read will see the write; it uses a best-effort approach.
BStrong consistency — reads may return stale values under high load.
CEventual consistency — reads always return the latest write within 1 millisecond.
DRead-your-writes consistency — writes are visible immediately to the writer but no one else.

A user posts a comment, then refreshes the page — but their comment doesn't appear. This is a symptom of which consistency violation?

javascript
Scenario (primary-replica DB):
  User writes comment  hits primary DB
  User reads page  load balancer routes to replica
  Replica is 200ms behind  comment not yet replicated
  User sees no comment despite just posting it  frustrated!

Read-Your-Writes consistency guarantee:
  After a write, the author always sees their own write in
  subsequent reads  even if other users don't yet.

Implementation strategies:
  1. After a write, route that user's reads to primary for 1 minute
     (session-based routing in the app layer)

  2. Track write timestamp in the session; read replica must be
     at least that version (version-based routing)

  3. Always read from primary (simplest but defeats replication purpose)

  4. For critical operations (payment, profile update): always
     hit primary directly
AMonotonic read inconsistency — the second read returned data older than the first read.
BRead-your-writes inconsistency — after a user performs a write, their subsequent reads are not guaranteed to reflect that write.
CStrong consistency violation — the database is not replicating fast enough.
DCausal consistency violation — the comment and the read are not causally related.

A user loads their dashboard twice. The first time they see 50 notifications; the second time they see 45. No one deleted notifications between the two reads. What consistency guarantee was violated?

javascript
The Problem:
  Read 1  Replica A (recently synced)  50 notifications
  Read 2  Replica B (lagging 5 minutes)  45 notifications
  
  User sees: notifications disappeared!
  This is "reading from the past"  a monotonic read violation.

Monotonic reads guarantee:
  If a user reads value X at time T, all subsequent reads by
  that user must return a value at least as recent as X.
  Reads can only move forward in time, never backward.

How to implement:
  Option 1: Session-based replica stickiness
    Assign each user session to a specific replica.
    That user always reads from the same replica.
    If the replica fails, re-assign (brief inconsistency allowed).

  Option 2: Read a version-fenced replica
    After read at version V, next read must hit a replica with version  V.
    Track the version in the session token.

  Option 3: Read from primary always (strong consistency, no stickiness needed).
AMonotonic reads — once a user has seen a value, subsequent reads should never return older data.
BRead-your-writes — the user's own writes are not visible.
CWrite-follows-reads — the write order doesn't match the read order.
DLinearizability — reads are not returned in a linear order across the system.

Sign up free to play

Answer all 10 questions (7 more), see explanations for every answer, and track your score.