patterntypescriptModerate

Eventual consistency patterns: read-your-writes and monotonic reads

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

eventual consistencyread your writesmonotonic readreplica lagconsistency tokencausal consistencystale read

Problem

A user submits a form, is redirected, and sees their old data because the read hit a replica that has not yet caught up. The user thinks their change was lost.

Solution

Implement read-your-writes consistency: after a write, route that user's subsequent reads to the primary (or the service that processed the write) for a short window. Use a sticky header or a logical clock token.

// After write: issue a consistency token
const token = await db.primary.getLastWriteTimestamp();
res.setHeader('X-Consistency-Token', token);

// On read: if token present and replica is behind, redirect to primary
const token = req.headers['x-consistency-token'];
if (token && (await replica.getCurrentTimestamp()) < token) {
  return readFromPrimary(req);
}

Why

Full strong consistency across all replicas is expensive. Targeted read-your-writes consistency satisfies the user experience requirement at a fraction of the cost.

Gotchas

Monotonic reads: a user should not see time go backward — once they see version N, never show them version N-1
Consistency tokens (causal consistency) are more general than sticky sessions and work across service boundaries
Inform users when the system is in a degraded state rather than silently showing stale data
Eventual consistency is not eventually wrong — every write will propagate; the question is when

Context

Systems with read replicas or CQRS read models where users see stale data after their own writes

Revisions (0)

No revisions yet.