Vertical vs horizontal scaling
You scale a system to handle more load; you can either make one machine bigger or add more machines.
Vertical scaling (scale up):
You give one server more power: more CPU cores, more RAM, maybe faster disks.
- Mechanism: same process, same machine, just higher limits.
- Example: your API server is hitting 80% CPU; you move from
4 vCPU / 8 GB RAMto16 vCPU / 64 GB RAM.
Horizontal scaling (scale out):
You run more copies of your service on multiple machines and put them behind a load balancer.
- Mechanism: the load balancer splits incoming requests across many instances.
- Example: instead of 1 large API server, you have 10 small ones, all running the same code, with a load balancer in front.
One concrete tradeoff each
| Approach | Main benefit | Concrete tradeoff / downside |
|---|---|---|
| Vertical scale | Simple: one box, no coordination | Hardware ceiling: you eventually hit the biggest machine size and a single failure takes everything down |
| Horizontal scale | Can grow almost arbitrarily, better fault tolerance | Complexity: need load balancing, health checks, consistency between nodes |
-
Vertical example tradeoff:
Your database on a single powerful machine is easy to manage, but if that machine dies, the database is simply down. Also, going from 32 to 64 cores may be cheap at first, but from 64 to 128 cores might be very expensive or not even available in your cloud region. -
Horizontal example tradeoff:
Your web app runs on 20 small instances, so one crash barely affects users. But now you must think about what happens to in‑memory sessions, which instance serves which user, and how to deploy without sending half of users to an older version.
Think: “Can I just buy a bigger box?” → vertical. “Can I run more boxes?” → horizontal.