Consistency models and eventual state

Consistency models and eventual state

Once state replicates, reads become interesting. The models, in the vocabulary system designers actually use:

• Strong / linearizable: every read sees every completed write, as if one copy existed. Costs: coordination on every read/write, availability drops under partitions.
• Read-your-writes (session): a client sees its own writes; others may lag. The pragmatic web default ("I edited my profile and I see my edit").
• Eventual: replicas converge given time and no new writes. Reads may be stale; the STALENESS is the contract to reason about.
• Causal: reads see all writes they causally depend on — comment sees the post it replies to.

The read-after-write trap (the practice drill, miniaturized): write to the primary, immediately read from a replica, and the read misses the write. Real systems hit this when load-balancers route a read to a replica after a POST. Fixes, in cost order: session pinning (route that user's reads to the primary for N seconds after a write), version checks (client sends the version it wrote; replica blocks/tells-stale), or accept and design for it (show "just saved" states optimistically).

Convergence is the other half: eventual systems need a well-defined convergence rule (last-write-wins by timestamp — with clock-skew hazards — or CRDTs for merge-able state). The checkpoint's EventualStore makes the delay explicit and observable: primary immediately, replica after a delay you control. The lesson is not the toy; it is the design habit — every distributed read/write decision should be able to name its consistency model and its staleness bound. If nobody can, that is the finding.