Home / System Design / Scalability: Vertical vs Horizontal Scaling

📈 Scalability: Vertical vs Horizontal Scaling

Fundamentals ⏱ 6 min read

Scalability is a system's ability to handle growing load — more users, more data, more requests — without falling over. There are two fundamental ways to scale, and knowing when to use each is a core system design skill.

Vertical scaling (scale up)

Add more power to a single machine — more CPU, RAM or faster disks. It's simple and needs no code changes, but it has hard limits: one machine can only get so big, it's expensive at the top end, and it's a single point of failure.

Horizontal scaling (scale out)

Add more machines and spread the load across them behind a load balancer. It scales almost without limit and improves fault tolerance (one node dying doesn't take everything down), but it adds complexity — you now need load balancing, data partitioning and coordination.

Stateless services are the key

Horizontal scaling works best when your application servers are stateless — any server can handle any request because no user data is stored on the server itself. Push session/state into a shared store (like Redis) or a token. Stateless servers can be added, removed or replaced freely.

The usual rule of thumb

Start by scaling up (simplest), but design to scale out. Large systems are almost always horizontally scaled because it's cheaper at scale and far more resilient. See load balancing for how the traffic gets distributed.

Frequently Asked Questions

Which is better, vertical or horizontal scaling?
Horizontal scaling is better for large, resilient systems because it has no single hard limit and tolerates node failures. Vertical scaling is simpler and fine for small systems or databases that are hard to distribute.
Why do stateless services matter for scaling?
If servers hold no per-user state, any server can serve any request, so you can freely add or remove servers behind a load balancer. State is moved to a shared cache or database instead.