We don't just test
syntax knowledge, we test your judgment.

When performance problems are user-specific, the problem is almost always in the data, not the code. Same code path, completely different data volume or shape.

First I look at data skew. The slow users likely have significantly more data associated with their account than the fast users. A query that returns 50 rows for a typical user might return 500,000 rows for a power user who has been on the platform for years. Run the query manually for an affected user and check the row count.

Then I run EXPLAIN ANALYZE with the affected user's data. The execution plan might look completely different. With a small result set the query planner might use an index. With a massive result set it might switch to a Seq Scan because it thinks that is faster. Understanding the planner's decision is key.

I also look for patterns among the slow users. Same region? Same account tier? Signed up before a certain date? Patterns point to the root cause. If all slow users signed up before a certain date, maybe older accounts have a data structure that newer ones do not.

Missing pagination is a common root cause here. The endpoint fetches all records for a user with no limit. For most users that is fine. For the 1% with massive data, it is catastrophic. Adding pagination or a hard limit fixes the immediate problem.

Check cache hit rates per user too. Power users who make many unique requests might have very low cache hit rates while typical users get cached responses most of the time.

First thing, bring the system back up. Quickly do a horizontal scale, meaning increase the number of servers. AWS, GCP, Azure does not matter. If auto scaling was on it should have triggered automatically. If not, you are triggering it manually right now. Every second counts.

But scaling alone is not enough. If 1 million users showed up at the door at the same time, you need a load balancer in front of them. Without it, all traffic hammers a single server even if you have ten of them running.

Then you ask yourself a critical question: do all these 1 million requests really need to reach the backend? No. Put a cache in between. Redis or Memcached, keep frequently requested data there. A homepage, a product listing, a leaderboard — these do not need a fresh DB query for every single user. Serve it from cache and your DB breathes again.

If the load on the DB is still too high after caching, open a read replica. Most traffic in most apps is reads, not writes. Separate them. Write to the primary, read from the replica. Your primary DB is now handling a fraction of what it was.

Once the fire is out, you do a proper post-mortem. Why did auto scaling not catch this? Was it a sudden spike with no ramp up? Did you have rate limiting in place? Could a queue have absorbed the burst instead of letting it hit the servers directly? These are the questions that prevent the next crash.

Same code, different environment. First thing I ask myself: where could the problem be?

First suspect is index. Dev has 1,000 rows, prod has 10 million. Without an index, the query scans the entire table. Run EXPLAIN ANALYZE and see what the query is doing. If you see Seq Scan, add an index and you are done.

If the index exists, next I check connection pool. In dev, a single user is hitting the query. In prod, hundreds of requests are coming in simultaneously. If the pool is full, queries are queuing up and waiting for a slot. Increasing the pool size usually fixes this immediately.

Still not found? Could be an N+1 problem. Sounds harmless but it is a killer in prod. You are firing 1000 queries instead of 1 without realizing it. Each loop iteration hits the DB separately. If using an ORM, check eager loading. One query with a join beats a thousand individual queries every time.

Also check DB server resources. Dev might have 16GB RAM, prod might have 2GB. Same query, completely different hardware. Query cache also comes into play here. A cold cache in prod means every query hits disk instead of memory.

Finally, network latency. In dev, the app and DB are on the same machine. In prod, they might be on different servers or even different regions. That difference alone can turn milliseconds into seconds.