Your API starts returning 500s and the logs are full of 'too many connections' from the database. Traffic is normal. Walk me through what you do, in order.
What they are really testing: They are testing whether you understand that connection exhaustion is almost always a client-side bug, and whether you stabilise the API before you go hunting for the leak.
A real interview question
Your API starts returning 500s and the logs are full of 'too many connections' from the database. Traffic is normal. Walk me through what you do, in order.
What most people say
drag me
“I would just increase max_connections on the database and restart the app so it clears the connections.”
Raising the limit hides a leak and can push the database into memory pressure, and a blind restart destroys the evidence you need to find the actual cause.
The follow-ups they ask next
How do you size the pool?
Multiply pool size by max instances and keep it under max_connections with headroom for admin sessions.
When does a proxy like RDS Proxy or PgBouncer actually help?
Talk about many short-lived clients such as Lambda or autoscaling tasks, and transaction pooling caveats.
What the interviewer is listening for
- Rolls back or restarts to restore service before diagnosing
- Reads pg_stat_activity by state and spots idle in transaction
- Does the pool size times instance count arithmetic out loud
- Proposes an alert threshold below the hard limit
What sinks the answer
- Raises max_connections as the fix and stops there
- Blames the database when traffic is flat
- Never checks whether a deploy correlates with the start time
- Cannot name a single query or metric they would look at
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“I have not debugged this exact failure, but here is how I would reason about it: connections flat at the ceiling with flat traffic points to a leak on the client side, so I would restore service first and then look at what is holding sessions open.”
Keep going with troubleshooting
Junior
You get paged at 2am. Checkout latency has gone from 200ms to 4 seconds and it started right after the 11pm deploy. Walk me through what you do.
Junior
It is 3am and you get paged: the primary application server is at 100% disk usage and the app is throwing write errors. You are the only one online. Walk me through exactly what you do.
Junior
You push a new version of a service and within two minutes the pods are all showing CrashLoopBackOff. The team is watching you share your screen. Walk me through exactly what you do.
Junior
A developer pings you: the checkout service cannot reach the payments service, the calls just hang and time out. You have never worked on either service. Walk me through what you do.
Junior
A developer messages you: 'My app suddenly gets Access Denied writing to the S3 bucket. Nothing changed.' It worked yesterday. Walk me through what you do.
Mid
Your load balancer shows 5xx errors jumping from 0.1 percent to 12 percent of requests over ten minutes. There was no deploy. What do you do?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free