Strong vs eventual consistency

The two models

• Strong consistency — after a write completes, every subsequent read (from any node) returns that value. The system behaves as if there’s one copy.
• Eventual consistency — reads may return stale data for a while; given no new writes, all replicas converge to the latest value eventually (milliseconds to seconds, usually).

What each costs

Strong requires replicas to coordinate before answering — a write must reach a quorum, and reads must be sure they see it. That coordination costs latency and, during a partition, availability (you may have to refuse the operation). Simple to reason about, expensive to provide.

Eventual lets any replica answer immediately from its local copy and propagate changes in the background. That buys low latency and high availability (stays up under partitions), at the cost of stale reads and the complexity of conflict resolution when concurrent writes diverge.

This is CAP and PACELC made concrete: strong = CP/EC, eventual = AP/EL.

How to choose — per data type

The senior move is to not pick one globally. Classify each piece of data:

• Needs strong: money and balances, inventory/seat counts, unique-username checks, authentication, anything where a stale read causes a wrong action.
• Fine with eventual: social feeds, like counts, view counts, profiles, recommendations, search indexes, analytics — where a few seconds of staleness is invisible or harmless.

“Show a slightly stale like-count? Fine. Sell the same concert seat twice? Never.” Same system, two different consistency choices.

The middle ground

Consistency isn’t strictly binary — name these when relevant:

• Read-your-own-writes — a user always sees their own updates immediately, even if others see them slightly later (e.g. your own tweet appears instantly).
• Monotonic reads — you never see time go backwards (a value you saw won’t un-happen on a later read).
• Causal consistency — operations that depend on each other are seen in order (a reply never appears before the message it answers).

These give “feels instant to the user” without paying for full global strong consistency.

The interview cue

When you place a data store, state its consistency explicitly and justify it: “Balances are strongly consistent via a quorum write; the activity feed is eventually consistent so it stays fast and available, with read-your-own-writes so the user always sees their own action immediately.” That sentence shows you treat consistency as a per-data design lever, not a database checkbox.