Chapter 9: Vertical vs Horizontal Scaling
Vertical Scaling (Scale Up)
Add more power to existing machine: more CPU, RAM, faster disk.
- Pro: Simple, no code changes, no distributed complexity
- Con: Hardware limits (can't buy a 10,000-core server), single point of failure, expensive at high end
- Limit: ~128 cores, 4TB RAM, ~100TB storage per machine
Horizontal Scaling (Scale Out)
Add more machines. Distribute load across them.
- Pro: Near-infinite scaling, redundancy (no SPOF), commodity hardware
- Con: Distributed systems complexity, network overhead, data consistency challenges
- Requires: Stateless services, load balancer, distributed data stores
When to Use Each
| Scenario | Approach | Why |
|---|---|---|
| Database (early stage) | Vertical | Simpler than sharding, buys time |
| App servers | Horizontal | Stateless = easy to replicate |
| Cache (Redis) | Horizontal (cluster) | Distribute keys across nodes |
| Database (at scale) | Horizontal (sharding) | Single node can't hold all data |
💡 Practical Strategy
Scale vertically first (it's simpler). When you hit hardware limits or need redundancy, scale horizontally. Most companies never need more than a few servers — don't over-engineer.
Key Takeaways
- Vertical: bigger machine. Simple but has limits and SPOF.
- Horizontal: more machines. Complex but unlimited and redundant.
- App servers: always horizontal (stateless)
- Databases: vertical first, horizontal (sharding) when forced
- Scale vertically until you can't, then go horizontal