Diagnosing slow auto-scaled PaaS workloads
layered debugging under load.
application metrics like request latency, throughput, and DB query time; infrastructure metrics like CPU, memory, and scaling lag.
jumping to add instances without isolating the real bottleneck.
What's really being asked
The interviewer wants disciplined, layered diagnosis rather than reflexively throwing more instances at the problem. Auto-scaling can mask or even worsen a bottleneck that lives outside the app tier.
The full answer
Name two distinct categories. Application metrics measure what the code is doing: per-endpoint request latency, throughput in requests per second, error rate, time spent in database queries, and time blocked on external dependencies. Infrastructure metrics measure the platform: CPU and memory utilization per instance, current instance count versus desired, request queue depth, network saturation, and how long the platform takes to react to a scaling trigger. The skill is correlating them.
The mistakes people make
Listing only CPU. Assuming auto-scaling makes performance problems impossible. Adding capacity without first confirming the app tier is the constraint, when the real limit is a single shared database or a third-party API.
What usually comes next
What does high latency combined with low CPU tell you. How would scaling lag itself cause poor performance during a traffic spike. How do you find a slow database query.
A concrete example
Suppose response times triple under load. You check infrastructure metrics and see CPU sitting at thirty percent across all instances even though more were added, so capacity is not the issue. You then look at application metrics and find that database query time dominates each request, and the connection pool is exhausted because every new instance opened more connections to a database that cannot keep up. The bottleneck is the shared data tier, and auto-scaling actually made it worse by multiplying connection pressure. The fix is at the data layer, through query optimization, caching, read replicas, or a connection proxy, not adding more application instances. A second pattern: high latency with healthy CPU and database but slow external dependency calls reveals a downstream service as the limiter. Separating the two metric families is what lets you point to the true cause quickly.
Interview question
Under load, latency triples but CPU stays at thirty percent across all auto-scaled instances. What does this combination most strongly suggest?
- a.Auto-scaling is adding too many instances
- b.A downstream dependency or shared database is the bottleneck, not compute capacityCorrect
- c.The instances need more CPU allocated
- d.Memory is the binding constraint
Why? this is the answer
Low CPU with high latency means compute is not saturated, so the delay comes from waiting on something else such as a database or external service. Adding CPU or instances would not help.
Just read this? Test yourself on what you have been reading.
- #observability
- #auto-scaling
- #performance
- #metrics
- #paas
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on observability — each one lists the topics its interview covers.
See open roles