Topic 13.4
Eventual Consistency
In one line
Replicas converge eventually — the default of any replicated system that doesn't synchronize every read.
Think of it like this
Posting something on social media: your friends on the other side of the world might see your post a second or two later than your friends nearby, but everyone WILL see it eventually. That small delay is usually fine.
Key ideas
- 01
Definition: updates propagate; given no further writes, replicas converge to the same value 'eventually'.
- 02
Where it comes from: async replication, caches, queues, AP stores during partitions.
- 03
The practical dial: staleness bounds — 'eventually' must mean 'within X seconds' for products to survive.
- 04
Read-your-writes + monotonic reads are the two practical guarantees you can add cheaply per-user.
- 05
Conflicts must be handled (couldn't merge): last-writer-wins (simple, lossy), versioned merge (CRDTs/vector clocks — complex).
- 06
Interview: 'eventual consistency with a 5-second staleness bound for feeds — but payments read the primary'.
Java / Spring map
- →
Spring: session read-your-writes via a user-affinity hint; caches with short TTLs produce bounded staleness.
Explain without notes
What is the cheapest guarantee that makes 'user posts → user sees own post' not embarrassing?
Practice
Design read-your-writes on a follower-heavy system (per-user route hint) and state the bound.
Trade-offs
- ↔
Eventual = fast + available, at staleness + merge-logic cost. Quantify the staleness in seconds, always.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I express eventual consistency with a time bound and a conflict-merge story.