Build the mental model
In a distributed system, the same piece of data typically lives on multiple replicas for availability and fault tolerance — but that immediately raises a question: when one replica is updated, when do the others see the new value? Strong consistency guarantees that every read, from any replica, immediately reflects the most recent write — but achieving that requires replicas to coordinate on every write (e.g., waiting for acknowledgment from a quorum) before responding, which adds latency and can block requests during network trouble. Eventual consistency relaxes that guarantee: a read right after a write might return a stale value, but if no new writes occur, all replicas will converge to the same value given enough time. The trade-off is speed and availability versus recency. This isn't an abstract choice — it's decided per use case. A 'likes' counter on a social post can tolerate a replica briefly showing 1,204 instead of 1,205; nobody notices or is harmed. A bank balance check before permitting a withdrawal cannot tolerate staleness — reading an outdated balance and allowing a withdrawal against money that's already been spent elsewhere is a real financial bug, not a cosmetic inconsistency.
Connect it to a real scenario
As the Tutorial Platform grows, its lesson-completion counters and 'X students enrolled' badges are replicated across regions for fast reads worldwide — these can safely use eventual consistency, since a badge lagging by a few seconds costs nothing. But when a user redeems a purchased course bundle, the system that checks 'has this payment already been applied' must use strong consistency: if two regional replicas disagree about whether the payment cleared, a student could be granted double course credits, or a payment could be dropped entirely. The Tutorial Platform's engineers don't pick one consistency model site-wide — they pick per data type, accepting eventual consistency (and its speed) everywhere staleness is harmless, and paying the coordination cost of strong consistency only where correctness genuinely depends on it.
Try the working example
BEFORE write (t=0):
Replica A: likes = 1204
Replica B: likes = 1204
[Client writes likes = 1205 to Replica A]
STRONG CONSISTENCY (e.g. bank balance):
t=0 Client -> Replica A: write likes=1205
t=0 Replica A <-> Replica B: synchronous sync (coordination)
t=1ms Replica A: ACK to client (write confirmed on all replicas)
t=1ms Client -> Replica B: read likes -> 1205 (always fresh, but write was slower)
EVENTUAL CONSISTENCY (e.g. like count):
t=0 Client -> Replica A: write likes=1205
t=0 Replica A: ACK to client immediately (fast!)
t=0 Client -> Replica B: read likes -> 1204 (STALE! B hasn't synced yet)
t=50ms Replica A --async replication--> Replica B
t=50ms Client -> Replica B: read likes -> 1205 (caught up / converged)The diagram shows strong consistency paying an upfront coordination cost so every subsequent read is immediately correct, while eventual consistency responds faster but can briefly return a stale value until replication catches up.5-minute try-it
Pick three features from an app you use daily (e.g. unread message count, follower count, account balance, order status). For each, decide whether eventual or strong consistency is appropriate, and justify why a stale read would or wouldn't cause real harm.
One important caution
Assuming 'eventually consistent' means 'consistent after a fixed, predictable delay' — in practice the convergence window can widen unpredictably under load or during network issues, so code that assumes staleness is always sub-second can be surprised.
Applying strong consistency everywhere 'to be safe' — this adds coordination latency to every single write and read across the whole system, even for data where staleness genuinely doesn't matter, needlessly slowing down the entire platform.
Wikipedia — Consistency model — System Design