Diagnosing post-deployment performance issues is a matter of using metrics and logs to pinpoint the bottleneck quickly, stabilizing production with a rollback if needed, then fixing and redeploying the root cause.
Key Points: • Monitoring tools like Prometheus for metrics and Grafana for dashboards reveal exactly when and where response times degraded. • Correlating a CPU or memory spike with a specific service points to inefficient code, such as an N+1 query or an unbounded loop. • If the issue is severe, rolling back to the previous stable version buys time to fix the problem without users continuing to suffer. • Once stabilized, the actual fix (query optimization, caching, code refactor) is applied and tested before being redeployed. • Continued monitoring after the fix confirms the issue is genuinely resolved and doesn't reappear under load.
Example: After a release, Grafana showed a sustained CPU spike traced back to a new endpoint doing a database call inside a loop; the team rolled back immediately, then fixed the query into a single batched call before redeploying.
Interview Tip: A concise interview answer is:
"I'd use Prometheus and Grafana to find exactly where response times degraded, which usually points to something like a CPU spike or a bad query. If it's serious, I roll back first to stabilize production, then fix and test the root cause before redeploying, and keep watching the metrics afterward to confirm it's really fixed."