Find out what is burning the CPU before you buy anything. If a handful of queries dominate, index or rewrite them. If it is genuine read volume, add replicas and route read only traffic there, then cache the hottest results with a short time to live. Removing N plus one patterns and capping page sizes often buys more than hardware. Scale the instance up to buy time, then fix the query pattern properly.
Why interviewers ask this
Interviewers want to see whether you profile before you spend. Adding replicas to a workload dominated by one unindexed query wastes money and hides the problem. They are also checking that you know replication is asynchronous, so moving reads introduces staleness you have to design around, and that caching carries a correctness cost. Strong answers order the fixes by cost, risk and time to implement.
How to structure your answer
- Measure which queries dominate before changing anything.
- Fix query and index problems first, they are cheapest.
- Add replicas or caching for genuine volume.
- Call out replication lag and how you handle it.
Example answer
Before I add anything I want to know what the CPU is doing, so I pull the top queries by total time from pg_stat_statements or the equivalent. In my experience a small number of queries do most of the damage, and often one of them is an N plus one from an ORM that got worse as a customer grew. Fixing that is free compared to running replicas. If the profile really does say even read volume, then replicas make sense and I route read only endpoints there. The catch is replication lag, so anything that reads straight after a write goes to the primary, otherwise a user watches their own update disappear. After that I cache the hottest few endpoints with a short time to live. In parallel I would scale the instance vertically, because that is a fifteen minute change that buys runway to do the rest properly. I try to be explicit with the team that scaling up is a timer, not a fix.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you route reads and writes in application code?
- How do you handle a user reading immediately after writing?
- At what point would you shard instead?
Related software engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions