Vertical vs horizontal scaling
Your one server is maxed out. Do you buy a bigger one, or buy more of them?
Open the interactive version → diagrams, practice & moreThe problem
Your one server is maxed out. Do you buy a bigger one, or buy more of them?
The idea
Vertical = a bigger machine (more CPU/RAM). Horizontal = more machines working together.
How it works
Vertical is simplest — no code changes — but hits a hardware ceiling, costs super-linearly at the high end, and stays a single point of failure. Horizontal scales near-limitlessly but the Universal Scalability Law warns the gains aren't free: each node adds coordination and data-coherency cost, so throughput can plateau or even decline past a point if contention dominates.
The tradeoff
Vertical: simple, bounded, fragile, pricey at the top. Horizontal: elastic and resilient but demands load balancing, a stateless app tier, and a real story for shared state and consistency. Most systems go vertical first (cheapest path) and horizontal when they need either the scale or the high availability one box can never give.
In the wild
You start on one box (vertical), then add a load balancer + many app servers (horizontal) as you grow.
Interview deep dive
Flow
- Start vertical: upgrade the box until cost or ceiling bites.
- Make the app tier stateless so it can replicate.
- Add a load balancer and a fleet of identical nodes.
- Push shared state into caches/DBs; plan for consistency.
Watch for
- One big box is a single failure from total outage, regardless of size.
- Scaling isn't linear — coordination cost can flatten gains (USL).
- Horizontal scaling just relocates the bottleneck to shared state.
Interviewer trap
Say why you scale horizontally — availability often matters more than raw capacity.