6. Vertical vs Horizontal Scaling
1
The picture to keep in your head2
6.1 What does "scaling" actually mean?3
6.2 What is vertical scaling?4
6.3 What is horizontal scaling?5
6.4 Why does scaling out need stateless servers?6
6.5 If servers are stateless, where does the state go?7
6.6 What is autoscaling, and how do you get it right?8
6.7 What about the database? Why is it the hardest part to scale?9
6.8 What does each kind of scaling really cost?10
6.9 So when do you choose which?11
Memory card and where the analogy breaks12
Practice: five levels13
Interview questions14
Solutions15
Sources16
Code lab6. Vertical vs Horizontal Scaling
6.9 So when do you choose which?
3 min read+10 XP
In the kitchen: A new café starts with one good chef. As it grows, it hires more chefs for the cooking, but keeps one carefully run pantry as long as it can, because splitting the pantry is a big, risky job.
In the system: In practice you use both, for different parts:
| Part | Usual choice | Why |
|---|---|---|
| Web and app servers | Scale out, at least 2 from day one | Stateless, cheap to add, survives failures |
| Database | Scale up first, then replicas, shard last | State is hard to split; one big machine goes far |
| Cache (Redis) | Up, then out (a cluster) | Simple until memory runs out (Chapter 13) |
| Background workers | Scale out on queue length | Each job is independent |
Rules of thumb:
- Always at least two of anything users depend on, even when one is enough for the load, so one failure isn't an outage.
- Scale up when it's cheap and quick, especially early and for stateful parts.
- Design for scale out in the stateless tiers from the start; it costs little to begin with and saves a painful rewrite later.
- Let the numbers decide (Chapter 2): a few hundred requests a second rarely needs anything clever.
Memory code: "Scale up to start, scale out to grow, and always keep two."