Horizontal vs Vertical Scaling Explained
When a system needs more capacity, there are exactly two ways to get it: make the machine you have bigger, or add more machines. Most real systems end up doing both — just not at the same time.
The quick answer
| Vertical (scale up) | Horizontal (scale out) | |
|---|---|---|
| How | Add CPU/RAM/disk to one machine | Add more machines behind a load balancer |
| Ceiling | Hard limit — there's always a biggest machine | Effectively none |
| Architecture changes | None needed | Requires statelessness, a load balancer, a data-partitioning plan |
| Failure tolerance | Still one machine — no redundancy | One instance dying doesn't take the service down |
| Cost | Downtime to resize, and steep cost near the top | Incremental — cost scales with demand |
Reach for vertical scaling when
- You need headroom fast and don't want to touch the architecture — it requires zero code changes.
- The system is still small enough that "biggest available machine" is nowhere close to being a real ceiling.
Reach for horizontal scaling when
- You've hit (or can see) the ceiling on vertical scaling, or downtime for resizing is no longer acceptable.
- You need redundancy — a single machine, no matter how big, is still a single point of failure.
- The workload can actually be split across machines — this is the real precondition people skip.
What horizontal scaling actually costs
It's not "more complex" in some vague sense — it's specific: every request now has to be routable to any instance, which means nothing about handling it can depend on state that only exists on one machine. A session, an in-memory cache, a WebSocket connection — each either needs to move to a shared store every instance can reach, or the system needs sticky routing, which reintroduces some of the coordination cost horizontal scaling was supposed to avoid. This is the same stateful vs. stateless tradeoff that shows up everywhere once you scale out.
The real-world pattern: vertical first, then horizontal
Almost no system picks one exclusively. The common, sensible order is: scale vertically first, because it's cheap and requires no architectural work, until the ceiling (or the downtime cost) starts to hurt — and only then invest in the real engineering work horizontal scaling requires. Databases follow this exact same progression.
Why this matters in an interview
"We'll scale horizontally" as a reflex undersells the tradeoff. A stronger answer names what would actually need to change to make the workload in the prompt statelessly splittable — session storage, cache externalization, whatever it is — rather than assuming horizontal scaling is a free lever to pull.
Go deeper
The full lesson has a decision diagram and a precise breakdown of what makes a workload "splittable" in the first place:
👉 Read the full Vertical vs Horizontal Scaling lesson — part of the free System Design Lab course.