Vertical vs Horizontal Scaling

Vertical vs Horizontal Scaling: a bigger machine, or more machines

3 min read

Vertical scaling makes one machine bigger — more CPU, more RAM, faster disk — while horizontal scaling adds more machines and spreads the work across them behind a load balancer. That one line is the whole choice. It is worth getting straight, because the difference between vertical scaling and horizontal scaling decides three things at once: how your system grows, how it fails, and whether the cost lands in the invoice or in your code.

Traffic outgrew one machine, and there are only two answers — make the machine bigger, or add more machines. Both are legitimate. Neither is the amateur move.

Scale up: one machine gets bigger

Vertical scaling is the one you reach for first, and usually correctly. You provision a larger instance type, move the workload onto it, and change nothing else. No load balancer, no session sharing, no distributed state — the application does not know it moved. That simplicity is the entire appeal, and for any workload that will never approach a single machine's limit, it is the right answer, not a compromise.

It costs you two things. The first is downtime: resizing an instance or patching its host usually means a restart, and that restart is user-visible. The second is a ceiling. Every machine has a top — the largest instance a cloud sells has a fixed CPU and memory count, and once you are on it there is nothing bigger to buy. The ceiling is a hardware fact, not a budget one.

Scale out: more machines share the load

Horizontal scaling runs N identical copies of the same application behind a load balancer that spreads requests across them. Capacity grows by adding nodes, so there is no single-machine limit to run into. Maintenance stops needing an outage, too — take one node out, patch it, put it back, repeat, and users never see a gap.

The cost here is paid in the application, not the invoice. The instances must be interchangeable, so any state that lived inside one process — in-memory sessions, local files, background timers — has to move out first. That migration to stateless instances is the real work of scaling out, and it is why "just add servers" is never just adding servers.

The big server has one plug

Here is the part that inverts most people's intuition. A bigger server feels safer — more headroom, fewer moving parts. It is the opposite. Vertical scaling concentrates the entire workload onto one machine, which makes that machine a single point of failure: when it goes, everything goes, because there is nothing to fail over to. Making the one machine bigger makes the blast radius bigger with it.

Horizontal scaling turns a total outage into a partial one. A node failing removes a fraction of capacity, not the service. You doubled the server, or you doubled what one outage can take down — that is the trade the failure mode is built on.

When to scale horizontally

The two names you will hear — scale up vs scale out — are the same choice under different words. Scale up (vertical) while it is simpler and cheaper, which is longer than most people assume. Scale out (horizontal) when you hit one of three walls: you are approaching the biggest instance available, a single point of failure is no longer acceptable, or you need to patch and deploy without downtime. Those three walls — the ceiling, the single plug, and downtime-free deploys — are when to scale horizontally; short of them, scaling up is still the lazier, cheaper, correct answer.

In practice most teams do both: scale up until the ceiling gets close, then scale out. The piece that forces the decision earliest is usually the database, because a stateful store is the hardest thing to spread across machines — which is why sharding exists as its own problem.

Vertical vs Horizontal Scaling in a system design interview

An interviewer is rarely asking which is better; they are checking whether you know the trade. The crisp answer: vertical scaling is simpler and correct until you hit a hardware ceiling or need to survive a single machine failing — at which point horizontal scaling wins on availability and headroom, at the cost of making your instances stateless. Say the failure line out loud: a vertically scaled system has one point of failure, a horizontally scaled one degrades instead of dying. Then name the catch: horizontal scaling only works if the nodes are interchangeable, and the database is usually the thing that isn't. That last sentence is what separates a memorized definition from someone who has actually run it.

Sources

• MongoDB — Horizontal vs Vertical Scaling
• CockroachDB — Vertical vs. Horizontal Scaling
• DigitalOcean — Horizontal Scaling vs Vertical Scaling
• Plesk — Horizontal vs Vertical Scaling