Replication Lag Cascade

synchronous_standby_names with ANY 1 (s1, s2, s3) and synchronous_commit = on makes a commit wait until any one of several standbys has the WAL, so a single slow or dead standby does not block writes the way a single named synchronous standby would. Be precise about what this buys you: it bounds staleness only for reads routed to a synchronous, caught-up standby, not for the whole read tier. Other asynchronous replicas can still lag freely. To turn it into a freshness guarantee you must direct the sensitive reads to an eligible synchronous standby, not just any replica. Reserve it for the write paths that truly need it; applying it everywhere pays the latency tax on writes that never had a freshness requirement.

After a write, capture a WAL position to fence on and carry it with the user (session, cookie, or token). pg_current_wal_lsn() read just after commit is a conservative fence: it returns a position at or after the transaction's commit LSN, so it never serves stale data but may occasionally route a read to the primary that a caught-up replica could have served. Capture the transaction's exact commit LSN if the driver exposes it and you want a tighter fence. Then serve that user's later reads from a replica only if pg_last_wal_replay_lsn() has reached the fenced position; otherwise read the primary. This gives read-your-writes for the one user who needs it without pinning all traffic to the primary, which is the difference between a targeted fence and throwing away your read scaling.

Route a given user's reads to the same replica by hashing a stable key such as user id, so their reads never jump to a more-lagged replica within a session. Cheaper than an LSN fence and sufficient when the problem is time going backward rather than not seeing one's own write.

Rate-limit or queue burst write operations so the primary does not produce WAL faster than replicas can sustain. Treats the cause (burst) rather than the symptom (stale reads), at the cost of added write latency during spikes.

Alert on a lag budget derived from the application's tolerance (for example warn at 500ms, page and demote at 5s). A replica past the budget is removed from the read pool until it catches up, so stale reads stop even before the root cause is found.