Overview
Vertical scaling (scaling up) means giving one machine more resources: more CPU, memory, or faster disks. Horizontal scaling (scaling out) means adding more machines and spreading the work across them. Vertical scaling is simple but hits a hardware ceiling and keeps a single point of failure; horizontal scaling is nearly unlimited and improves availability but requires the software to be designed for distribution.
Most real systems use both: scale vertically until it is expensive or risky, then scale horizontally. Stateless tiers (web and API servers) scale out easily behind a load balancer; stateful tiers (databases) are harder and need replication or sharding.
Vertical scaling is hiring a faster chef and buying a bigger stove; eventually no chef is fast enough. Horizontal scaling is opening more kitchens with the same recipes; you need a host to route orders and a way to share ingredients.
When to use it
- Vertical: early-stage products, databases that are hard to split, quick relief.
- Horizontal: traffic beyond one machine, high availability, elastic demand.
- Horizontal for stateless services; carefully planned for stateful ones.
- Cost optimization: many small instances vs one large instance.
Where it shows up in interviews
Recognize it when: traffic grows 10-100x.
- Scale a single-server app to millions of users
- Design Instagram's backend
Recognize it when: the database is the bottleneck.
- Design Twitter's storage
- Scale a relational database beyond one node
Where it is used in real software
Famously served huge traffic from a small number of powerful SQL Server machines, showing how far vertical scaling can go.
AWS Auto Scaling, GCP managed instance groups, and Kubernetes HPA add or remove instances automatically based on load.
Amazon RDS lets you change instance size (vertical) and add read replicas (horizontal reads).
Key terms
- Scale up
- Bigger machine.
- Scale out
- More machines.
- Stateless service
- Any instance can serve any request because state lives elsewhere.
- Elasticity
- Adding and removing capacity automatically with demand.
- Single point of failure
- A component whose failure takes the whole system down.
How it works, step by step
- 1Measure the bottleneck
CPU, memory, disk I/O, network, or the database?
- 2Scale up for quick relief
Resize the instance; often minutes of downtime or a failover.
- 3Make the tier stateless
Move sessions and files to Redis and object storage.
- 4Scale out behind a load balancer
Add identical instances; enable auto scaling.
- 5Scale the data tier
Caching, read replicas, then partitioning or sharding.
Vertical vs horizontal
Key differences
| Aspect | Vertical | Horizontal |
|---|---|---|
| Limit | Largest available machine | Practically unlimited |
| Complexity | Low (no code changes) | Higher (distribution, state) |
| Availability | Single point of failure | Survives instance failures |
| Cost curve | Grows faster than linearly at the top end | Roughly linear |
| Downtime to scale | Often a restart | None (add instances) |
NOWAspect: Limit | Vertical: Largest available machine | Horizontal: Practically unlimited
Start simple, but design stateless services from day one so scaling out later is a configuration change, not a rewrite.
Implementation
apiVersion: autoscaling/v2kind: HorizontalPodAutoscalermetadata: name: apispec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api minReplicas: 3 # at least one per availability zone maxReplicas: 50 metrics: - type: Resource resource: name: cpu target: { type: Utilization, averageUtilization: 65 }Complexity and performance
Vertical ceiling is high but finite.
Containers vs VMs.
Trade-offs
One big server is easier to run and debug but is a single point of failure.
Horizontal systems need load balancing, shared state, and handling of partial failures.
Variants and related techniques
Scale up to a sweet spot, then scale out with that instance size.
Split the system by feature into separately scaled services.
Common mistakes
- Local state in app servers.
Fix: Externalize sessions, uploads, and caches before scaling out.
- Scaling the wrong tier.
Fix: Adding web servers does not help if the database is saturated.
Interview questions
How would you scale a single-server web app to millions of users?
Separate the database, put stateless app servers behind a load balancer with auto scaling, add a cache and CDN, add read replicas, move slow work to queues, and eventually shard the data.
Why is horizontal scaling harder for databases than for web servers?
Databases hold state. Spreading writes across machines requires partitioning data and handling consistency and cross-shard queries, while web servers can simply be cloned.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Scale from 1 to 1M users step by step | Medium | Tier-by-tier evolution. |
| Decide scale-up vs scale-out for a reporting database | Medium | Trade-offs. |