What is the difference between horizontal and vertical scaling?
Vertical scaling (scaling up) makes one machine bigger with more CPU, RAM or faster disks. Horizontal scaling (scaling out) adds more machines and spreads the load across them. Vertical is simpler but has a hard ceiling and a single point of failure; horizontal scales further and survives failures but needs stateless services and a load balancer.
Explain it simply
Your college canteen has one cook and the lunch queue is getting long. You have two options.
Vertical scaling: hire a faster cook and give them a bigger stove. One kitchen, more power. It is easy, nobody has to change how orders work. But there is a limit to how fast one person can cook, and if that cook falls sick, nobody eats.
Horizontal scaling: open three more counters with three more cooks. Now you need someone at the entrance pointing people to a free counter, and every counter must follow the same menu and recipes. It is more work to organise, but you can keep adding counters, and if one cook is absent, the others continue.
Example
Vertical:
Before: 1 server, 4 vCPU, 16 GB RAM
After: 1 server, 32 vCPU, 256 GB RAM
-> No code change. Brief downtime to resize. Still one machine.
Horizontal:
Before: 1 server, 4 vCPU, 16 GB RAM
After: 6 servers, 4 vCPU, 16 GB RAM each, behind a load balancer
-> Sessions moved to Redis, uploads moved to object storage.
-> Add or remove servers as traffic changes. One server dying is fine.How it works
| Vertical (scale up) | Horizontal (scale out) | |
|---|---|---|
| What changes | Bigger machine | More machines |
| Limit | Largest machine available | Very high, in practice |
| Failure | One machine is a single point of failure | Others keep serving |
| Code changes | Usually none | Services must be stateless; data must be shared or partitioned |
| Extra parts | None | Load balancer, shared cache or session store |
| Cost curve | High-end machines get expensive fast | Many commodity machines, pay as you grow |
| Downtime to scale | Often a restart | Usually none |
Stateless is the key idea. For horizontal scaling to work, any server must be able to handle any request. So you do not keep login sessions, carts or uploaded files on one server's memory or disk. You move them to a shared store such as Redis, a database or object storage.
Databases are harder. App servers scale out easily. A database holds state, so you first scale it vertically, then add read replicas for reads, and finally shard (split data across machines) when one writer is not enough.
Real-world use
- A new startup runs on one medium server and simply upgrades it as users grow. That is sensible early on.
- During an IPL final, a streaming service adds hundreds of extra servers for the video and API layers, then removes them after the match. That is horizontal scaling with autoscaling.
- Many teams keep the main database on one large machine (vertical) with read replicas, while scaling the stateless web tier horizontally.
Common mistakes
- Saying horizontal scaling is "always better". It adds network calls, coordination and operational work.
- Scaling out app servers while sessions are stored in local memory, so users get logged out when the next request hits a different server.
- Forgetting the database. Ten app servers hitting one overloaded database is still slow.
- Ignoring that a bigger machine still means a single point of failure.
What to say in the interview
"Vertical scaling means adding CPU, memory or faster disks to one machine. It's simple and needs no code changes, but it has a hardware ceiling and the machine stays a single point of failure. Horizontal scaling means adding more machines behind a load balancer. It scales much further and tolerates failures, but the app must be stateless, with sessions and files in shared stores. In practice I scale the stateless web tier horizontally with autoscaling, and scale the database vertically first, then with read replicas, caching and eventually sharding."
Follow-up questions
- What does it mean for a service to be stateless?
- How do you scale a database horizontally?
- What is sticky session, and why is it usually avoided?
- When is vertical scaling the better choice?
Go deeper
Read these once the basics above feel easy.
Horizontal scaling works well with autoscaling: add servers when CPU or request rate crosses a target and remove them when traffic drops. For the database, read replicas help read-heavy apps but introduce replication lag, so a user may not see their own write immediately unless you route that read to the primary.
Sharding splits data by a key such as user ID. Choosing the shard key decides whether load is even and whether queries can stay on one shard. Consistent hashing reduces data movement when shards are added. Cross-shard queries and transactions become expensive, so many systems design data models to avoid them.