Read replica lag climbing
A migration creates an index on a large hot Postgres table to speed up a new query. The author used `CREATE INDEX CONCURRENTLY` to avoid blocking writes — good. The primary stays healthy. But minutes after the migration starts, every read replica falls far behind: replica lag climbs to minutes, and the read-heavy app (which routes reads to replicas) starts serving very stale data and breaching freshness SLOs; some read endpoints time out. The primary's write traffic is normal. How do you triage and mitigate, and what's the subtlety the author missed?
What a strong answer looks like
Stop the bleeding first (mitigate), then form hypotheses from real signals. Separate root cause from symptom, communicate status as you go, and close with what prevents a repeat.
0:00 of about 35 min
Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.
Run or narrate your approach, then ask the coach.