// System Design · 05
Consistency Models
A promise about how fast a write becomes visible elsewhere.
How it fits together
- Author creates Primary (1 write Ana)
- Primary uses / calls Author (4 read own write)
- Primary replicates / copies Replica (2 async, lag 2s)
- Other user fails / error path Replica (3 stale read)
Spot it
- A user saves, refreshes, and sees the old value
- Read replicas lag behind the primary
- Two services disagree about the same record
It costs
Stronger guarantees cost latency and availability; weaker ones push the complexity into the app.
In code
public sealed class ProfileReader( IProfileStore primary, IProfileStore replica, IRecentWrites recentWrites){ public async Task<Profile?> GetAsync(Guid userId, Guid viewerId, CancellationToken ct) { var wroteRecently = await recentWrites.ContainsAsync(viewerId, ct); var store = wroteRecently ? primary : replica; return await store.FindAsync(userId, ct); }}Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
Strong: every read sees the latest write. Eventual: if writes stop, replicas converge. Between them sit useful middles — read-your-writes, monotonic reads, causal consistency.
Most UX bugs blamed on "eventual consistency" are really a missing read-your-writes guarantee for the person who just made the change.
Event-driven systems are eventually consistent by design. Make consumers idempotent and show the user a pending state instead of pretending it is done.
Ask for it
- strong consistency
- eventual consistency
- read-your-writes
- replication lag
- idempotency
Reads go to a replica and users see stale data right after saving. Give me read-your-writes consistency for the author of a change while keeping everyone else on replicas.