Scalability: Vertical vs Horizontal
Beginner · 13 min read · High-Level Design, Scaling the Application Tier
Scaling up vs out, stateless services, and where state should live.
Scalability is a system's ability to handle increased load by adding resources — while keeping performance acceptable. A system that serves 100 users well but falls over at 10,000 is not scalable. A system that handles 10,000 users only because someone rewrote it from scratch is not scalable either.
Load can mean many things, and you should be specific about which one you're scaling:
Performance vs scalability
These are related but different:
Vertical scaling (scale up)
Add more power to a single machine: more CPU cores, more RAM, faster disks.
Horizontal scaling (scale out)
Add more machines and distribute the load among them.
Comparison
Stateless services: the key to scaling out
A service is stateless if any instance can handle any request because no instance holds data that other instances need. All durable state lives in external stores (databases, caches, object storage).
Where systems typically bottleneck
A typical evolution as a system grows:
Auto-scaling
In cloud environments, horizontally scaled tiers can grow and shrink automatically:
Scaling dimensions beyond "more servers"
The Scale Cube (from The Art of Scalability) names three axes:
Interview questions
- Why is horizontal scaling preferred for web servers but often delayed for databases?
- What are the problems with sticky sessions?
- Your auto-scaling group doubled app servers during a spike, and the site still went down. What might have happened?
- When would you choose vertical scaling in a modern design?
Practice
Write your answer before opening the suggested one. If you mark it "Partly" or "Missed it", it comes back in your review deck.
Further reading
Key takeaways
- Vertical scaling is simple but capped and creates a single point of failure; horizontal scaling is unbounded but adds complexity.
- Make services stateless — move sessions and data to shared stores — so any instance can serve any request.
- State doesn't vanish; it moves to the data tier, which then becomes the bottleneck.
- Scale the cheap tier (stateless compute) first; add data-tier complexity (replicas, then sharding) only when needed.
- Auto-scaling must account for warm-up time and downstream capacity.