Core Concepts

What is Strong vs Eventual Consistency?

Consistency models describe what a reader is guaranteed to see after data is written. Under strong consistency, once a write succeeds every subsequent read returns it. Under eventual consistency, replicas may briefly disagree, but if writes stop they all converge to the same value. Most large systems mix the two: strong where correctness demands it, eventual everywhere else.

In simple words

Strong consistency is like a shared Google Doc: everyone sees the edit instantly. Eventual consistency is like news travelling between villages: everyone hears it, but not at the same moment. For a like counter the second is fine; for a bank balance it isn't.

Strong: acknowledge only after replicas have it. Eventual: acknowledge first, copy later, so a reader may briefly see the old value.

Why It Matters

Replicated data lives in several places, and copying takes time. Waiting until every copy (or a quorum) agrees gives correct reads but costs latency and availability; answering from the nearest copy is fast but may be stale. The consistency model is how you decide, per feature, which cost to pay.

How It Works

Strong: write is acknowledged only after it's durable on enough replicas
        that every later read (from any node) sees it.
          write x=2 --> [A] [B] [C] all/quorum updated --> ack
          read  x   --> 2, from anywhere

Eventual: write acknowledged by one node; others catch up asynchronously.
          write x=2 --> [A] ack      [B] x=1  [C] x=1   (for a few ms/s)
          read  x   --> 1 or 2 depending on the replica
          later     --> 2 everywhere (converged)

Models In Between

Read-your-writes: a user always sees their own updates (others may lag). Fixes the "I saved my profile and it reverted" bug.
Monotonic reads: a user never sees data go backwards in time (stick them to one replica).
Causal consistency: if B is a reply to A, nobody sees B without A.
Bounded staleness: reads may lag by at most X seconds or N versions.

When to Use Which

Strong	Eventual (often + read-your-writes)
Account balances, payments, ledger	Like/view counts, follower counts
Inventory decrement, seat booking	News feed, timelines, recommendations
Unique usernames / short codes	Product catalog, search index
Locks, leader election, config	Analytics, logs, notifications

Key Pointers

Strong = correct and simple to reason about; costs latency and availability during failures.
Eventual = fast and highly available; the app must tolerate stale reads and resolve conflicts.
Quantify "eventual": "followers see a new post within ~5 seconds".
Read-your-writes covers most user-visible staleness complaints cheaply.

Follow-up Questions

How do eventually consistent stores resolve conflicting writes?: Last-write-wins by timestamp (simple, can silently drop a write), version vectors that detect concurrent writes and keep both for the app to merge, or CRDTs, data types that merge automatically (counters, sets).
A like count is off by a few for some seconds. Is that a bug?: Not if the requirement allows it; counts are a classic eventual-consistency case. Say so in the design, and make sure the count converges (no lost increments).