Eventual Consistency Introduces Temporal Uncertainty
“Eventual consistency is not a consistency guarantee: it is a propagation delay promise. Under normal conditions, propagation is fast. Under failure, propagation delay is unbounded. ”
Eventual consistency systems are correct during periods of low propagation delay. They are uncertain during high-load periods when replication lag grows. They are incorrect during failure scenarios where propagation halts entirely. Every system that adopts eventual consistency must explicitly model: the acceptable propagation window, the operational procedures when that window is exceeded, and the data hazards created by prolonged staleness. Without this modeling, eventual consistency is a correctness risk, not just a latency tradeoff.
Why It Matters
A read from a PostgreSQL read replica is not "eventually consistent" in the abstract. It is consistent within the current replication lag: which is 10ms under normal load, 200ms under write pressure, and minutes during a primary failover. The consistency window is dynamic, not static. Users reading account balances, inventory counts, or subscription status from eventually consistent paths may be reading data that was correct seconds ago but is not correct now. The probability of a stale read is not constant: it tracks directly with system load.
Failure Modes
- ·Stale read during replication lag spike causes incorrect business logic decisions
- ·Consumer lag growth makes event-driven analytics increasingly misleading
- ·Cache TTL expiry during high-traffic period causes inconsistent reads within the same session
- ·Failover-induced replication reset causes extended staleness window for all read replicas
- ·CQRS read model rebuild lag during deployment causes temporarily incorrect read responses
Amplification Risks
- ⚡Stale read feedback loop: stale reads cause incorrect application logic, creating incorrect writes, which compound the staleness
- ⚡Consumer lag cascade: slow consumers fall further behind under load, creating increasingly stale downstream systems
- ⚡Cache stampede on TTL expiry: all caches expiring simultaneously under load creates a burst of primary reads
Temporal Behavior
- ⟳Consistency windows are dynamic: they expand under load and contract during quiet periods
- ⟳After a primary failover, consistency windows are at their maximum and shrink as replicas catch up
- ⟳Consumer lag windows are unbounded in failure scenarios: they must be bounded by explicit consumer SLA enforcement
- ⟳TTL-based cache consistency creates predictable expiry but unpredictable in-flight request inconsistency
Boundary Implications
- ◈Every eventually consistent read path is a temporal boundary between write and read visibility
- ◈Consistency SLAs define the acceptable size of that temporal boundary
- ◈Crossing the consistency boundary under failure: returning stale data beyond the SLA window: is a correctness incident, not just a performance incident
Topology
- ·Read replica topology creates bounded-but-variable consistency windows on every read path
- ·Cache nodes create invalidation windows that are bounded only if TTLs are set deliberately
- ·Event stream consumer topology creates consumer-lag windows that must be monitored as consistency metrics
Scaling
- ·Higher write volumes increase replication lag and therefore increase consistency windows
- ·More consumers in event-driven systems create wider variance in propagation windows across the consumer fleet
- ·Cross-region replication multiplies propagation latency: consistency windows span seconds to minutes
Resilience
- ·Systems with explicit consistency-tier routing are resilient to replica failures without correctness compromise
- ·Without per-operation consistency classification, replica failures create ambiguous correctness incidents
- ·Runbooks must specify which operations fall back to primary reads during replica degradation
Governance Implications
- ·Every eventually consistent read path must have an explicit maximum acceptable staleness SLA
- ·Consistency-sensitive operations must be annotated and routed to consistent read paths
- ·Monitoring for replication lag must treat lag as a consistency metric, not just a performance metric
Evolution Implications
- ·Moving to strongly consistent reads requires infrastructure investment in synchronous primary routing
- ·Read model synchronization during CQRS evolution requires careful lag analysis during migration
- ·Audit of which business operations use eventually consistent paths is a required prerequisite for consistency model evolution
Mitigation Patterns
- →Classify every read operation as consistency-sensitive or eventually-consistent
- →Route consistency-sensitive reads to the primary; eventually-consistent reads to replicas
- →Set maximum acceptable lag thresholds and trigger alerts before they affect user-facing operations
- →Build consistency degradation runbooks: procedures for each scenario where lag exceeds thresholds
- →Use write-through cache invalidation over TTL-only for high-consistency paths
Cross-References