The "Good Problem"
You built an app, and it's successful. Traffic is growing exponentially. That's a good problem to have — until your database server hits 100% CPU and everything slows to a crawl. The database is almost always the first bottleneck because, unlike stateless web servers, you can't just clone it and put a load balancer in front without careful thought.
Two Paths to Scale
When a single machine can no longer handle the load, you have two main options:
- Vertical Scaling (Scaling Up): Move the database to a bigger, more expensive machine with more CPU cores, more RAM, and faster disks.
- Pros: Simple. No architecture changes needed. Your application code doesn't change at all.
-
Cons: There's a hard ceiling to how big a single machine can be. The cost curve is non-linear — doubling performance often costs four times as much. You still have a single point of failure.
-
Horizontal Scaling (Scaling Out): Spread the load across multiple machines.
- Pros: Virtually limitless capacity. Better resilience — losing one node doesn't take down the whole system.
- Cons: Significantly increases architectural complexity. Your application must be aware of, or shielded from, the distributed nature of the data.
In practice, most teams exhaust vertical scaling first (it's simpler), then layer in horizontal techniques as load demands it. In this topic, we will explore the main techniques for horizontal scaling: Read Replicas for scaling reads, Sharding for scaling writes, and Connection Pooling to manage the traffic between your application and the database.