Vertical vs horizontal scaling

Think of it like this

Analogy

Your bakery can't keep up with orders. You can buy a bigger oven (vertical scaling) or buy more ovens and hire more bakers (horizontal scaling).

A bigger oven is easy: same kitchen, same process. But ovens only come so big, the giant ones cost a fortune, and if it breaks, you bake nothing. More ovens can grow almost without limit and one breaking isn't a disaster, but now you need someone to hand out orders and a way for every baker to follow the same recipe.

The problem it solves

Traffic grows and one server stops keeping up: CPU is maxed, memory runs out, responses slow down and eventually time out. You need more capacity, and you have two very different ways to get it. Picking the wrong one either wastes engineering time or leaves you stuck at a ceiling.

A real example

Example

Exam results day

A school board publishes exam results on a website that runs on one server. Most of the year it's nearly idle.

The first year results go online, the site crashes at 9:00 when 200,000 students log in at once. The next year they scale vertically: a machine with 4 times the CPU and memory. It survives, barely, and the upgrade needed a maintenance window.

The year after, they scale horizontally. Six smaller servers sit behind a load balancer, with sessions stored in a shared cache so any server can answer any student. For results day they add 14 more, then remove them that evening. The cost follows the traffic, and losing one server no longer takes the site down.

How it works

Vertical scaling (scale up)

Vertical scaling moves you to a bigger machine: more CPU cores, more memory, faster disks. In the cloud it's often a matter of stopping the instance, choosing a larger type and starting it again.

Good: no code changes, no new moving parts, and everything stays on one machine, so there are no network calls between pieces and no data to keep in sync.
Bad: there is a ceiling (the largest instance), prices rise steeply near the top, resizing usually means a restart, and the one machine is still a single point of failure.

Databases are often scaled up first, because spreading a database across machines is hard.

Horizontal scaling (scale out)

Horizontal scaling runs more copies of the same server and spreads requests across them with a load balancer (lesson 6).

Architecture

Scaling up keeps one larger server. Scaling out puts several identical servers behind a load balancer.

Good: nearly unlimited growth, small machines are cheap, one failing doesn't take you down, and you can add or remove machines without downtime (and automatically, in lesson 8).
Bad: you need a load balancer, and the app must be built so any server can handle any request. That means stateless servers (lesson 7), shared storage for files, and a database every server can reach.

The usual path

Start with one modest server and scale it up while that's cheap and easy.
Make app servers stateless, then scale them out behind a load balancer. This is usually easy.
Scale the database up as far as is sensible, add caching and read replicas, and only then consider splitting the data across machines (sharding, lesson 12), which is hard.

Stateless tiers scale out; stateful tiers (databases) scale up first and out later, with care.

Rough comparison

Aspect	Vertical	Horizontal
Effort	Low	Medium (app must be stateless)
Limit	Largest machine available	Very high
Survives one machine failing	No	Yes
Downtime to grow	Usually a restart	None
Cost curve	Rises steeply at the top	Roughly linear

Trade-offs

What you gain

Vertical: simplest possible change, no distributed-systems problems.
Horizontal: grows far beyond one machine, tolerates failures, and scales down to save money.

What it costs you

Vertical: hard ceiling, single point of failure, expensive at the top, restart to resize.
Horizontal: needs a load balancer and stateless design; more machines to manage and monitor.

When not to use it

Avoid scaling out a database before you've tried scaling up, caching and read replicas; sharding adds lasting complexity.
Avoid scaling up forever when you need high availability; one machine can always fail.

In the cloud

Groups of identical serversEvery major cloud sells this as a managed service, so you configure it rather than build it.

AWS1

Amazon EC2 Auto Scaling groups (opens vendor docs)
A group of identical EC2 instances built from one launch template, kept at the size you set.

Azure1

Azure Virtual Machine Scale Sets (opens vendor docs)
A group of identical VMs you can grow or shrink together.

Google Cloud1

Managed instance groups (opens vendor docs)
Identical Compute Engine VMs created from one instance template, with auto-healing.

How you’d set it up

Scaling out — a load balancer in front of a group of identical servers built from one template.

Application Load Balancer
Launch template
Auto Scaling group of EC2

Interview questions

Try answering out loud first, then open the model answer.

Vertical or horizontal scaling: which would you choose and why?

Model answer

Both, for different tiers. For stateless app servers I'd scale horizontally behind a load balancer from early on, because it's cheap and gives redundancy. For the database I'd scale vertically first because it's simple and keeps transactions on one machine, and add read replicas and caching to offload reads. I'd only shard when a single primary can't handle the write volume or data size, because sharding makes queries, transactions and operations harder.

What has to change in an app before you can scale it horizontally?

Model answer

Any state stored on the server must move out: sessions go to a shared store or into signed tokens, uploaded files go to object storage, in-memory caches become a shared cache or are fine to be per-server, and scheduled jobs need to run on only one instance (with a lock or a separate worker). Configuration should come from the environment so every instance is identical. Then a load balancer with health checks spreads traffic.

Is horizontal scaling always cheaper?

Model answer

Not always. Many small machines can cost about the same as one big one, but you add a load balancer, more operational overhead and network calls between machines. At small scale, one well-sized server is often the cheapest and simplest option. Horizontal scaling pays off through elasticity (shrinking at night), resilience, and the ability to grow past the biggest machine.

Quiz

Pick an answer to see whether it’s right and why.

0 of 6 answered

Key terms

Vertical scaling: Making one machine bigger (more CPU, memory or disk). Also called scaling up.
Horizontal scaling: Adding more machines and splitting the work between them. Also called scaling out.
Single point of failure: One component whose failure takes the whole system down.
Stateless service: A service that keeps no user data between requests, so any copy of it can answer any request.
Load balancer: A component that receives incoming requests and spreads them across several servers.