How would you scale a relational database as traffic grows?
Interviewer Expectations for this Question
01
Core Competency
Assesses fundamental understanding of DBMS conventions, runtime behavior, and memory/performance considerations.
02
Evaluation Criteria
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Comprehensive Model Answer
Verified Solution
Scaling relational databases follows a progression, because a single node eventually hits CPU, memory or I/O limits.
- Optimise first: fix queries, add indexes, tune the buffer pool and connection pooling, and archive old data.
- Read scaling: add replicas and route reads to them, accepting replication lag. Use a cache such as Redis for hot data.
- Vertical scaling: more RAM and faster disks, such as NVMe, often beat complex sharding and buy time.
- Partition large tables by range or hash to keep working sets manageable.
- Shard: split data across nodes by a shard key so writes scale. This makes cross-shard joins, transactions and unique constraints hard.
app -> primary (writes)
| replication
v
replicas (reads) + cache
Choose the shard key for even distribution and locality, and plan resharding and rebalancing. Some workloads are better served by a NoSQL or NewSQL store, or by CQRS with separate read and write models.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.