Vertical vs Horizontal Scaling

Scalability introduced the two ways to give a system more capacity: make one machine bigger, or add more machines. This lesson is the deeper, dedicated head-to-head that lesson promised — the first, and in many ways the template, for every other paired tradeoff in this module.

Vertical scaling: a bigger machine

Vertical scaling ("scaling up") means adding more CPU, RAM, or faster disks to an existing machine. It requires no changes to application architecture — the code doesn't know or care that it's running on a bigger box — which makes it the fastest possible way to buy more headroom. It has three hard limits, though: there's a biggest machine you can actually rent or buy, resizing typically means real downtime while the machine restarts with new specs, and a single bigger machine is still exactly one machine — it doesn't help with Single Point of Failure risk at all, since there's nothing to fail over to.

Horizontal scaling: more machines

Horizontal scaling ("scaling out") means adding more machines and spreading load across them, coordinated by a Load Balancer — the piece of infrastructure that's the whole reason horizontal scaling is usable in practice rather than just a theoretical option. It has effectively no ceiling (keep adding machines) and directly buys redundancy (one instance dying doesn't take the whole service down), but it requires the workload to actually be splittable across machines, and it requires a plan for any state that would otherwise live on one machine — which is why so much of this course (sharding, replication, Stateful vs. Stateless Design) exists downstream of this one architectural choice.

System Design Lab

The real-world answer is almost always both, in sequence

Very few systems pick one exclusively. The common, sensible pattern is to scale vertically first — it's cheap, fast, and requires zero architectural work — until the ceiling or the downtime cost of the next resize starts to hurt, and only then invest in the real engineering work horizontal scaling requires (a load balancer, statelessness, data partitioning). This mirrors exactly the progression Database Scaling lays out for databases specifically: cheap vertical headroom first, architectural horizontal changes once that's genuinely exhausted, not before.

What horizontal scaling actually costs, precisely

It's worth being specific about why horizontal scaling isn't free, beyond "it's more complex": every request now has to be routable to any instance, which means nothing about handling that request can depend on state that only exists on one specific machine. A user's session, an in-memory cache, a WebSocket connection — anything like this either needs to be externalized to a shared store all instances can reach, or the system needs sticky routing to keep a given client on the same instance, which itself reintroduces some of the coordination cost horizontal scaling was meant to avoid.

Why this matters in an interview

"We'll scale horizontally" as a reflex, without acknowledging that it requires the workload to be statelessly splittable, undersells the tradeoff. A stronger answer names what would need to change to make horizontal scaling possible for the specific workload in the prompt — often exactly the Stateful vs. Stateless Design tradeoff — rather than assuming it's a free lever to pull.