System Design · Architecture under constraints
What does scalability mean in system design?
Short answer
Scalability is the ability to handle growth in load or data without a disproportionate loss of performance or increase in cost. It is about removing the current bottleneck, then the next one.
Scalability is not a synonym for performance. A fast system can still fail to scale if its capacity is capped by a single database or a shared lock. Scaling means adding resources or changing the architecture so that capacity grows with demand while latency and cost stay within target.
Two directions
- Vertical scaling: a bigger machine, simpler but bounded by hardware and often by cost
- Horizontal scaling: more machines, which requires stateless services and partitionable data
- Elastic scaling: add and remove capacity with demand, which needs fast startup and health checks
- Functional scaling: split a workload into independent services or shards with separate bottlenecks
Every system has a limiting resource: CPU, memory, disk IOPS, network, connection count, lock contention or a human operational process. Find the saturated resource under peak load and fix that first. After the fix, the bottleneck moves, so scaling is an iterative exercise rather than a one-time configuration.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What is usually the first bottleneck after adding web servers?
- 2When would you choose vertical scaling over horizontal?
- 3How do you find the actual bottleneck under load?
- 4Why does elasticity require statelessness?
Say it in the interview
Scalability means handling more load or data without collapsing latency or cost. I look for the resource that saturates first, fix it, and expect the bottleneck to move somewhere else. Vertical scaling is simpler but bounded, while horizontal scaling needs stateless services and data that can be partitioned. I treat scalability as an iterative bottleneck-removal process, not a property you declare once.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live System Design mock interview and get scored feedback on depth, clarity and confidence.