Lock contention on hot merchant
Postgres. An order-processing service uses a per-merchant `SELECT ... FOR UPDATE` on a single `merchant_balances` row to serialize balance updates. After onboarding one very high-volume merchant, that merchant's order p99 hit 8 s and its workers spend most time waiting; other merchants are fine. `pg_stat_activity` shows many sessions on `Lock` / `transactionid` all targeting that one merchant's balance row. Throughput per worker is low. Triage and redesign so a single hot merchant doesn't serialize itself into the ground.
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 30 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.