Strong vs Eventual Consistency

Database Architectures and Change Data Capture both pointed here for the read-side consequence of replicating or propagating data across multiple places: once more than one copy of something exists, what can a reader actually rely on seeing? Strong and eventual consistency are the two ends of that answer.

Strong consistency: every read sees the latest write

Under strong consistency, once a write is acknowledged, every subsequent read — from any replica, anywhere — is guaranteed to see it. There's no window where a client can observe stale data. This guarantee isn't free: achieving it typically means a read has to be confirmed by enough replicas (or routed to the one authoritative replica) to be sure it reflects the latest write, which adds real latency and can reduce availability if those replicas aren't reachable — directly the CP side of the CAP Theorem's tradeoff.

Eventual consistency: it'll catch up

Under eventual consistency, a write is acknowledged quickly, and replicas converge on the same value eventually — usually within milliseconds to seconds — but a read immediately after a write, especially from a different replica, can return stale data. This is the direct read-side consequence Change Data Capture already named: every CDC-fed downstream system is eventually consistent with the source database by design, not by accident.

System Design Lab

Why anyone would choose weaker guarantees on purpose

Eventual consistency isn't a compromise made reluctantly — for a large class of data, it's the correct choice, because strong consistency's cost (latency, reduced availability under partition) buys a guarantee the application doesn't actually need. A social media "like" count being briefly stale by a few hundred milliseconds is imperceptible to any user and costs nothing real; forcing every reader worldwide to wait for a globally-confirmed count on every page load would be paying real latency for a correctness guarantee nobody benefits from.

Where strong consistency earns its cost

The other direction matters just as much: a bank balance, an inventory count being decremented at checkout, or anything where two people acting on stale information causes a real, irreversible problem (overselling the same last item, double-spending a balance) needs strong consistency — the cost of a slower read is trivial compared to the cost of the application acting on wrong information. This is the same "what can the application actually tolerate" question CAP Theorem raises generally, applied specifically to the read path.

It's not really binary — there's a spectrum

Real systems often land somewhere between the two extremes rather than picking one absolutely: read-your-own-writes consistency guarantees a client always sees their own writes immediately (so a user who just posted a comment sees it appear, even if other users briefly don't), without paying for full strong consistency across every reader globally. Quorum-based systems (write to W replicas, read from R replicas, chosen so W + R > N) can tune how strong a guarantee they provide continuously, rather than treating it as an all-or-nothing switch — a system doesn't have to pick a single global answer for every piece of data it holds.

Why this matters in an interview

The strongest answer to "does this need strong or eventual consistency" is one grounded in what happens if a reader sees stale data for that specific piece of data — not a system-wide default. A design that reasons per-data-type ("the payment ledger needs strong consistency, the view counter doesn't") demonstrates real judgment; reflexively picking one for the whole system does not.