read_replica vulnerable to replication_lag

read replicaVulnerable Toreplication lag cascade

Source: Pattern·Target: Failure Mode

Summary

The read replica pattern is structurally vulnerable to replication lag cascade because its value proposition: serving reads from replicas: depends on replica data being sufficiently current. Any condition that delays WAL replay degrades or invalidates the replica's usefulness.

Evidence

·Replication lag spikes documented during bulk writes, DDL, and long transactions
·Applications routing reads to lagged replicas have served stale data silently
·PostgreSQL provides no built-in SLA on replication lag under load

Operational Context

·Application must implement lag-aware routing: reject lagged replicas or fall back to primary
·Monitor pg_replication_slots for inactive logical replication slots (can cause unbounded WAL growth)
·Set max_standby_streaming_delay and max_standby_archive_delay based on consistency requirements

Tradeoffs

·Synchronous commit eliminates lag but halves write throughput
·Lag-aware routing adds application complexity and requires replica health metadata
·Aggressive lag thresholds shift all traffic to primary under load, negating scale benefits

Generator Relevance

Any architecture generation including read_replica must include replication lag monitoring and lag-aware routing in the operational requirements output.

Evidence grounding

Grounded, 3 supporting items

Direct structural dependency. Every production read replica deployment must account for this failure mode. Lag cascade has been the cause of multiple high-profile data consistency incidents.