Read-After-Write Consistency

Replica lag matters.

Overview

Read-after-write consistency ensures that a user who just wrote a value can immediately read it back. Naive replica routing breaks this expectation: the user writes to the primary, the read load-balances to a replica, the replica has not yet replicated the write, the user sees the old value and reports a "bug" that is actually replica lag. The discipline is to recognise the problem, route read-after-write paths to primary briefly, and pick a strategy that matches the user expectation rather than fight it.

• Replica lag matters. Reading from a stale replica returns the old value; the user reports a "bug" that is actually replication lag.
• User expectation. Users expect to see their own writes immediately; preserving this is preserving trust.
• Read-from-primary. Simplest fix: route the user’s reads to primary for a brief window after their write.
• Session affinity plus causal consistency. Cookie or token routes the user briefly; causal consistency tracks the write timestamp and ensures replicas have caught up.

The approach

The practical approach is to route read-after-write paths to primary for a brief window (matched to typical replication lag, usually 1-5 seconds), use session affinity (cookie or token) where the user’s subsequent reads need to land consistently, monitor replica lag continuously so routing logic can adapt, document the per-table consistency expectation, and test the consistency model with synthetic tests before production.

• Read from primary after write. Brief window where the user’s reads go to primary; matches the typical replication lag window.
• Session affinity. Cookie or token routes the user; supports consistent reads across the affinity window.
• Monitor replica lag. Per-replica lag metrics inform routing logic; routing adapts to actual lag rather than assumed lag.
• Documented policy plus test consistency. Per-table consistency expectation committed to the schema documentation; synthetic tests reveal edge cases before production.

Why this compounds

Read-after-write discipline compounds across features. Each correctly-routed read preserves user trust; each documented consistency expectation supports debugging the next user-reported "bug" that is actually a consistency issue; the team builds intuition for distributed-systems consistency that pays off on every new feature.

• User experience. Users see their own writes; the trust the user has in the system stays intact.
• Debugging. Consistency model documented; the next user-reported issue can be debugged against the actual model.
• Operational fit. Right consistency for the workload; not over-paying for global consistency where eventual works.
• Institutional knowledge. Each consistency issue teaches replication patterns; the team builds vocabulary for distributed-systems debugging.

Read-after-write consistency is a distributed-systems discipline that pays off across years. Nova AI Ops integrates with database telemetry, surfaces consistency patterns, and supports the team’s consistency discipline.