SeniorTroubleshooting

Support says customers are updating their profile and then seeing the old value straight after. Replica lag on your read replica is at 40 seconds and climbing. Take me through it.

What they are really testing: They want to see if you can separate the correctness symptom from the infrastructure symptom, protect users first, and reason about why a single-threaded apply stream falls behind.

A real interview question

Support says customers are updating their profile and then seeing the old value straight after. Replica lag on your read replica is at 40 seconds and climbing. Take me through it.

What most people say

drag me

Replication lag happens sometimes, so I would wait for it to catch up and tell support it is temporary.

It accepts a live correctness bug as normal, it offers no way to protect users during the lag, and it never asks what pushed the replica behind in the first place.

The follow-ups they ask next

  • How do you give read-after-write consistency without sending all reads to the primary?

    Sticky reads for a short window after a write, or wait for the replica to reach the write LSN before reading.

  • Lag drains but comes back every night at 1am. What do you look at?

    A scheduled job, a nightly backup or an ETL competing with the apply stream.

What the interviewer is listening for

  • Fixes the customer-visible correctness issue before the lag itself
  • Distinguishes shipping bytes from applying them, using LSN offsets
  • Suspects a batch job or backfill as the write source
  • Proposes a lag budget that backfills must respect

What sinks the answer

  • Treats lag as normal and tells support to wait
  • Scales the replica with no evidence of a resource limit
  • Never mentions where the extra write volume came from
  • Cannot explain what read-after-write consistency means

If you genuinely do not know

Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.

I have not run this exact incident, but here is how I would reason about it: the stale read is a routing problem I can fix immediately, and the lag is a throughput problem I then trace back to whatever started writing more.

Keep going with troubleshooting

All 336 cloud engineer questions

Knowing the answer is not the same as recalling it under pressure

Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.

Start free