Scalability — Vertical vs Horizontal

Build the mental model

When a single server can no longer keep up with load, there are exactly two directions to go: scale vertically (buy a bigger machine — more CPU, more RAM, faster disks) or scale horizontally (add more machines and split the load across them). Vertical scaling is simple: the application code doesn't need to change, there's no coordination between machines, and it works immediately — but it has a hard physical ceiling (there's a biggest machine money can buy) and it creates a single point of failure, since one machine going down takes the entire system with it. Horizontal scaling has no such ceiling; you can, in principle, keep adding machines indefinitely, and losing one machine only degrades capacity rather than causing a full outage. The cost is complexity: the application generally must be stateless (any server can handle any request, since a user's session or data isn't pinned to one specific machine) and something has to distribute traffic across the fleet. Because vertical scaling's ceiling and single point of failure become unacceptable at real production scale, most modern systems default to horizontal scaling despite the extra engineering it demands.

Connect it to a real scenario

Right now the Tutorial Platform could run on one upgraded server, and for a while that's the correct, cheapest choice — buying a bigger machine is far less work than rearchitecting the app. But there's a ceiling: once enough learners are studying lessons simultaneously, no single machine is big enough, and one crash would take the entire platform offline for everyone. The platform's real growth path is horizontal — running the same Next.js app on multiple servers behind a load balancer (the next lesson) — which requires first making the app stateless, a constraint every later lesson in this course assumes.

Vertical scaling = bigger machine; simple, no code changes, but has a hard ceiling and a single point of failure.
Horizontal scaling = more machines; scales further and survives individual failures, but requires a stateless app and traffic distribution.
Most modern production systems default to horizontal scaling despite its added complexity, because the ceiling of vertical scaling is unacceptable at real scale.

Try the working example

text

VERTICAL SCALING                        HORIZONTAL SCALING
----------------------                  ----------------------------
      +--------+                          +----+  +----+  +----+
      | BIG    |                          | S1 |  | S2 |  | S3 |
      | SERVER |                          +----+  +----+  +----+
      | (CPU++ |                              \      |      /
      |  RAM++)|                               \     |     /
      +--------+                            +------------------+
                                             |  Load Balancer   |
+ Simple, no code changes                   +------------------+
+ Works immediately                         + No hard ceiling
- Hard ceiling (biggest box                 + One server dies,
  money can buy)                              others keep serving
- Single point of failure                   - Requires stateless app
  (it dies, everything dies)                 - Needs traffic distribution

You should see

The diagram compares scaling one server up against spreading load across many servers behind a load balancer, labeled with each approach's trade-offs.

5-minute try-it

Think of an app of your own and decide: if users grew 10x, could vertical scaling still handle it, or would you need horizontal scaling — and why?

One important caution

Scaling vertically as the only strategy until hitting the largest instance size available from the cloud provider, then having no next step except a costly rearchitecture under production pressure.

Scaling horizontally by adding servers while the app still stores session data in local memory, so a user's requests randomly land on a server that doesn't have their data — logging them out or losing their cart contents unpredictably.

Wikipedia — Scalability — System Design