Horizontal vs Vertical Scaling
Understand when to scale up (vertical) vs scale out (horizontal), how to design stateless services for horizontal scaling, session management at scale, and autoscaling strategies.
Understand when to scale up (vertical) vs scale out (horizontal), how to design stateless services for horizontal scaling, session management at scale, and autoscaling strategies. This hands-on tutorial focuses on practical implementation of horizontal vs vertical scaling concepts.
Horizontal vs Vertical Scaling
Scalability is the ability of a system to handle increasing load by adding resources. There are two fundamental approaches: scaling up (get a bigger machine) or scaling out (get more machines).
Vertical Scaling (Scale Up)
Vertical scaling means upgrading the existing server — more CPU, more RAM, faster SSD.
Pros & Cons of Vertical Scaling
| ✅ Pros | ❌ Cons |
|---|---|
| Simple — no code changes needed | Hard ceiling — biggest machine has limits |
| No distributed system complexity | Single point of failure — one machine goes down, system dies |
| Lower latency (no network hops) | Downtime required for hardware upgrade |
| Great for databases (initially) | Expensive — cost scales super-linearly |
Horizontal Scaling (Scale Out)
Horizontal scaling means adding more servers of the same size and distributing load across them.
The Golden Rule: Stateless Services Enable Horizontal Scaling
Scaling Strategies in Practice
Autoscaling
Modern cloud platforms (AWS, GCP, Azure) support autoscaling — automatically adding or removing servers based on load.
| Metric Trigger | Action | Example |
|---|---|---|
| CPU > 70% for 5 min | Scale out (add servers) | AWS EC2 Auto Scaling |
| CPU < 20% for 10 min | Scale in (remove servers) | Save cost at night |
| Request queue depth > 100 | Scale out workers | SQS + Lambda |
| Custom metric (RPS) | Scale out web servers | K8s HPA |
[!TIP] Scale out for stateless services, scale up for stateful (databases). Databases are hard to horizontally scale — start with vertical scaling and read replicas, then shard only when absolutely necessary.
Quiz
Quiz
Question 1 of 2What is the primary reason horizontal scaling requires stateless services?
Official Resources
- The Art of Scalability — AKF Partners (Book)
- AWS Auto Scaling Documentation
- Google Cloud — Scaling Strategies
- Designing Data-Intensive Applications — Martin Kleppmann (Chapter 1)
Key Takeaways
✅ Vertical scaling is simple but has a hardware ceiling and creates a single point of failure.
✅ Horizontal scaling is the key to massive scale — but requires stateless services.
✅ Make services stateless by moving session state to external shared storage (Redis).
✅ Autoscaling dynamically matches capacity to demand — critical for cost efficiency at scale.
✅ Scale databases vertically first, add read replicas, then shard — horizontal DB scaling is complex.
What's Next?
Now that we can add more servers, we need to distribute traffic across them.
Next: Load Balancing — algorithms, layers, and how to pick the right strategy.