Under load, your RDS instance is the bottleneck and the app is slowing down. Walk me through your options, in order.
What they are really testing: Whether you triage a database bottleneck methodically, cheapest and least risky first, instead of jumping to "shard it" or "make the instance bigger". They want you to diagnose before you scale and to know read replicas are not a write fix.
A real interview question
Under load, your RDS instance is the bottleneck and the app is slowing down. Walk me through your options, in order.
What most people say
drag me
“I would upgrade to a bigger RDS instance, and if that is not enough I would shard the database.”
It skips diagnosis entirely and leads with the two most expensive levers. A bigger instance hides a missing index instead of fixing it, and sharding is a massive, hard-to-reverse change reached for far too early. No mention of caching, replicas, indexes, or pooling.
The follow-ups they ask next
You added read replicas but users report stale data right after a write. Why, and what do you do?
Replication lag: replicas are eventually consistent. Route reads that must be fresh (read-after-write) to the primary, and only send tolerant reads to replicas. Or use a session/consistency strategy so the user who just wrote reads from the primary briefly.
Connections are maxed out even though CPU looks fine. What is going on?
Connection exhaustion, often each app instance opens its own pool and they add up, or connections are not being released. Put RDS Proxy (or an app-side pooler) in front to multiplex, and check for leaked/long-held connections.
What the interviewer is listening for
- Diagnoses the specific resource before scaling
- Leads with indexes, query fixes, and pooling
- Knows replicas scale reads only and add lag
- Treats sharding as a last resort
What sinks the answer
- Jumps straight to a bigger instance or sharding
- No diagnosis step
- Thinks read replicas help writes
- Ignores caching and connection pooling
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.
“First I would diagnose [CPU / IOPS / connections / slow queries] with [Performance Insights and slow query logs]. Cheap fixes first: [indexes, fixing N+1, RDS Proxy for connections]. Then offload reads with [ElastiCache and read replicas, which help reads only]. Then [vertically scale the instance] for headroom. Only last would I [partition or shard], because it is the most invasive.”
Keep going with databases
Foundation
What is a database index, how does it speed up queries, and what does it cost?
Foundation
What are the ACID properties of a database transaction?
Foundation
What is normalization, and what are primary and foreign keys?
Junior
A query is slow in production. How do you diagnose and fix it?
Junior
Why is database connection pooling important, especially at scale?
Junior
How do read replicas help scale a database, and what is replication lag?
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