Strong, Eventual, and Causal Consistency: The Consistency Spectrum

The Profile Picture Bug

A user updates their profile picture. They see the new picture. They reload the page - old picture is back. Reload again - new picture. This is eventual consistency making itself visible. The user's update landed on one replica, but their reads got routed to a replica that had not caught up yet. This problem is why consistency levels matter.

Strong Consistency

After a write completes, every subsequent read (from any node) returns that write. The system behaves as if there is only one copy of the data. This is what you get from a single-server database.

Strong Consistency:

  Client writes X=5 to Leader
       |
  Leader ----replicate----> Follower A
       \---replicate----> Follower B
       |
  Wait for ALL to confirm
       |
  'Write successful'
       |
  ANY node now returns X=5    <-- guaranteed

  Cost: Every write waits for ALL replicas = SLOW
  Latency: 50-200ms (cross-DC: 100-300ms)
  Availability: If any replica is down, writes block
  Use when: Wrong data = real damage (money, inventory)

Eventual Consistency

If no new writes occur, all replicas will eventually converge to the same value. But there is no bound on how long 'eventually' takes (in practice, usually milliseconds to seconds).

Eventual Consistency:

  Client writes X=5 to Node A
       |
  'Write successful' immediately
       |
  Node A --async replicate--> Node B (5ms later)
  Node A --async replicate--> Node C (50ms later)

  Time T+0:    Node A=5, Node B=3, Node C=3  (stale!)
  Time T+5ms:  Node A=5, Node B=5, Node C=3  (still stale!)
  Time T+50ms: Node A=5, Node B=5, Node C=5  (converged)

  Cost: Writes are FAST (no waiting)
  Reads: Might return stale data
  Use when: Stale data is OK (social feeds, analytics, caches)

Causal Consistency

A middle ground: if event A caused event B, everyone sees A before B. Unrelated events can be seen in any order. This matches how humans expect things to work.

Causal Consistency:

  Alice posts: 'I got the job!'        (event A)
  Bob replies: 'Congrats!'              (event B, caused by A)
  Charlie posts: 'Nice weather today'   (event C, unrelated)

  Valid orderings anyone can see:
    A -> B -> C     (OK, B after A)
    C -> A -> B     (OK, B still after A, C is unrelated)
    A -> C -> B     (OK, B still after A)

  INVALID:
    B -> A -> C     (BAD! B was caused by A, must come after)

  Tracks causality with vector clocks or Lamport timestamps.
  Cheaper than strong consistency, more useful than eventual.

Read-Your-Writes Consistency

After you write something, YOUR subsequent reads will always see that write (even if other users still see the old value). Prevents the frustrating profile picture bug described earlier.

Read-Your-Writes:

  User updates email to new@example.com
       |
  Write goes to Replica A
       |
  User refreshes settings page
       |
  Option 1: Route reads to same replica (sticky sessions)
  Option 2: Include write timestamp, only read from
            replicas caught up past that timestamp
  Option 3: Read from leader for 'own' data

  Result: User ALWAYS sees their own changes.
  Other users might see old email briefly - that is OK.

Choosing Your Consistency Level

Use Case                Consistency Level    Why
----------------------  -------------------  ---------------------------
Bank balance            Strong               Wrong balance = real damage
Inventory at checkout   Strong               Overselling costs money
User profile (own)      Read-your-writes     User must see own changes
Chat messages           Causal               Replies must follow posts
Social media feed       Eventual             Stale feed beats error page
Analytics dashboard     Eventual             Approximate counts are fine
Recommendations         Eventual             Stale recs still useful
Collaborative editing   Causal               Edits must preserve order

Interview Tip

When discussing consistency in an interview, say: 'I would not use the same consistency level everywhere. For the payment ledger, I need strong consistency - a wrong balance is unacceptable. For the social feed, eventual consistency is fine - a slightly stale feed is better than higher latency. For the user's own profile, I would use read-your-writes so they always see their changes immediately.' This shows you understand the trade-offs and can make practical decisions.

Key Takeaway

Consistency is a spectrum. Strong consistency is safest but expensive. Eventual consistency is cheapest but allows stale reads. Causal consistency preserves logical ordering of related events. Choose the weakest consistency level that still produces correct behavior for each use case.