Stop 20 · System DesignTopics · 2/15

Vertical vs Horizontal Scaling

In short

When one server isn't enough, you have two choices: make it bigger, or add more of them. Each has a ceiling and a cost, and real systems usually use both.

Vertical scaling means using a bigger server (more CPU/RAM); horizontal scaling means using more servers — each with very different cost, complexity and ceiling trade-offs.

The purple blob stands between one giant pressure cooker and a row of small ones.

Think of it like this

One giant cooker or many small ones

For a big family function, you can buy one huge pressure cooker or borrow four normal ones. The giant one is simple, but cookers only come so big, and if its whistle breaks, dinner's off. Four small ones need coordination, but one failing isn't a disaster.

Watch it happen

Scale up or scale out?

Vertical (scale up)

Bigger CPU and more RAM, same machine
No code changes needed
Hard ceiling, single point of failure

Horizontal (scale out)

More machines behind a load balancer
App must be stateless
Grows far and survives failures

Scale up first because it's easy. Design to scale out when you need more room or high availability.

The big ideas

What you need to know

Vertical is the quick fix

Resize the VM or database to a bigger instance. Often just a short restart, and no code change.

Horizontal needs statelessness

Sessions, uploads and caches must live outside app servers, or users break when they land on a different one.

Horizontal adds resilience

With three servers, one crashing means a third less capacity, not a full outage.

Databases resist scaling out

Stateless apps scale out easily. Databases usually scale up first, then add replicas, and shard only when they must.

See it in code

Walk through the code

bash

1# Vertical: stop, change the size, start (short downtime)2aws ec2 stop-instances --instance-ids i-0abc1233aws ec2 modify-instance-attribute --instance-id i-0abc123 \4  --instance-type Value=m7i.xlarge5aws ec2 start-instances --instance-ids i-0abc1236 7# Horizontal: tell the auto scaling group to run more copies8aws autoscaling set-desired-capacity \9  --auto-scaling-group-name api-asg \10  --desired-capacity 6

1/2Scaling up one machine means stopping it, picking a larger type, and starting it again.

In practice you'd let the auto scaling group add and remove instances based on CPU or request count, instead of setting the number by hand.

Save yourself the pain

Common mistakes

Oops

Scaling out an app that keeps state in memory.

Do this instead

Carts and sessions vanish when the next request lands elsewhere. Move state to Redis or the database first.

Oops

Running one huge server and calling it production-ready.

Do this instead

When it reboots for patches, everything is down. Two smaller servers across zones beat one giant one for uptime.

Your mission

Try both

~35 min

Quick check

Which approach needs no code changes but has a hard upper limit?

Go deeper

1List the practical limits of vertical scaling — there's a biggest server you can buy.
2Learn why horizontal scaling requires your app to be stateless.
3Identify which type of scaling a project you know actually uses today.