Strong consistency and high freshness usually trade off; products must pick

What it is

The same money cannot be spent in two places at once, and the same list cannot always jump onto every screen at once — not both at the extreme. Strong consistency and high freshness trade off. Getting everyone onto one edition, including one’s own just-written value, costs coordination time, and freshness yields. Letting each node paint the latest stroke first is fast, and a brief “each sees their own” appears. A product has to say which end this region prefers. Writing both as “we want both” is not a choice.

Why it happens

Propagating state among replicas takes time. Waiting until every replica admits the same edition before showing it to a person yields a consistent view that is late — the coordination stretch is the freshness loss. Admitting locally first and shipping later yields a fast view, while someone else may still see the old edition, and a value just written may not have arrived on another device. Distributed systems write this as a choice between latency and agreement: in the normal case, short delay or strong agreement; under partition, keep writing or stop and wait for agreement.

The interface counterpart is not a protocol name. It is which of two failures is less acceptable. Spending a balance twice, overselling stock, entering after permission was already revoked — consistency failures, whose cost is a false fact. A list two seconds late, an avatar still the previous one, a collaborative caret that hitch-steps — freshness failures, whose cost is an old fact. Both annoy; the repairs run opposite ways. Prefer agreement, and people wait, or writes are briefly refused. Prefer freshness, and the product must be ready to roll back, to show conflict, and to say “what you see may not be the final edition”.

Where it stops holding

Single machine, single user, no replication: the trade-off barely exists; do not paste distributed language onto it. Ledgers that must be strongly consistent in law (payments, title transfer, vote counts) cannot be switched to eventual agreement so the screen jumps faster. A pure display stream whose intermediate frames may be dropped (an approximate headcount) gains nothing from strong agreement. Different regions of one product may pick different ends: payments strong, a feed fresh — provided people are not invited to treat the feed’s numbers as the ledger. The trade-off flips under failure: a system that usually picks freshness often must stop writes during a partition, and the UI must be ready to say “cannot change now” rather than keep pretending to be live.

Applying it

• Write a preference for data that can be gotten wrong: must-not-be-wrong goes to strong agreement; brief each-sees-their-own goes to high freshness. Put it in product language, not only on an architecture diagram.
• On a strong-agreement region: do not paint a write as successful before it is confirmed; a read must be able to see one’s own just-confirmed write.
• On a high-freshness region: allow brief forks, with visible conflict and rollback, and do not pipe those numbers into a strong-agreement decision.
• How to check: in an environment where replica delay can be stretched, ledger-like operations should go slow or refuse rather than succeed twice. Feed-like operations should still paint, and after catch-up must not leave two facts. Labelling both ends “fast and absolutely consistent” with no drill of either failure counts as not having chosen.

Related

• Same group: I4.07.1 Different features need different freshness; not everything must be latest · I4.07.2 Freshness expectations follow content type, not what the system can do · I4.07.3 Label freshness so people do not misread how current the data is
• Nearby: I3.02 Optimistic updates · I3.04 Sync conflicts
• Search terms: consistency versus freshness · strong consistency · eventual consistency