What they're testing
Whether you understand consistency as a per-read-path choice rather than a system-wide switch.
The short answer~30 seconds
This is replication lag breaking read-your-writes. Four fixes, coarse to fine: read the primary for everything (which discards the replica's value); pin the writer to the primary for a few seconds after their write (simple, effective, my usual choice); pass the write's LSN/GTID and wait for the replica to catch up before reading (most precise, most machinery); or accept the lag and render the UI from what you just wrote rather than re-fetching.
The user saves their profile. The primary commits and returns success immediately.
The long answer
The key point is that you do NOT need strong consistency on every read path. A leaderboard three seconds stale harms nobody; a profile that shows pre-edit data makes the user hit save again and gives you a duplicate-write bug. So the good answer classifies read paths: which must reflect the caller's own writes, and which needn't.
The session-pinning approach works because real lag is usually sub-second while the write-then-read behaviour lasts a few seconds. Set a cookie or a Redis key w:{user} with a 5-second TTL, and route that user's queries to the primary during it. The cost is a tiny fraction of read traffic going back to the primary, in exchange for the bug disappearing entirely.
The LSN-waiting approach is the one worth raising in a senior round: after the write, take pg_current_wal_lsn(), carry it to the read path, and compare against the replica's pg_last_wal_replay_lsn() before reading; if it hasn't arrived, either wait briefly or fall back to the primary. It buys exactly the semantics you need without sacrificing all read traffic — provided you also handle the replica that never catches up because it's stuck.
One last thing to say out loud: lag isn't a constant. It spikes during large backfills, heavy VACUUMs, or when the replica is I/O-starved. If your system quietly assumes "lag is always under 100ms", it will break on your busiest day. Measuring and alerting on lag is part of the answer, not an addendum.
What they'll ask next
?Does synchronous replication solve it outright?
Yes, but you pay in write latency — every commit waits for at least one replica to acknowledge — and in availability: if the replica dies, writes stall unless synchronous_standby_names is configured with enough members. This is precisely the "Else" branch of PACELC.
?Measure lag in bytes or seconds?
Both, because they answer different questions. Bytes (pg_wal_lsn_diff) tell you how much is left to replay; seconds (replay_lag) tell you how stale what the user sees is. A low-write system can sit at zero bytes while replay_lag still jumps, simply because there was nothing to replay.
These lose points
- "Route all reads to the primary" and stopping there. Then your replica is just an expensive standby.
- Treating lag as a small constant. It's a long-tailed distribution, and the tail is what causes incidents.
Sources
- PostgreSQL — Hot Standby: replay conflicts and `pg_last_wal_replay_lsn()`
- PostgreSQL — Synchronous Replication (`synchronous_commit`, `synchronous_standby_names`)
- Daniel Abadi — PACELC: even without a partition, you still choose between latency and consistency