Scalability explained: vertical vs horizontal scaling
Scalability is the ability to handle more load without a redesign. Here is the difference between scaling up and scaling out, and where systems usually break first.
A system is scalable if it can handle more users, data or requests by adding resources, without rewriting it. Scalability is not "fast". A page can be fast for one user and fall over for ten thousand.
Vertical scaling (scale up)
Give one machine more CPU, RAM or disk.
- Pros: simple, no code change, no distributed-systems problems.
- Cons: there is a ceiling, big machines get expensive fast, and one machine is still one point of failure.
Horizontal scaling (scale out)
Run many ordinary machines behind a load balancer.
- Pros: almost no ceiling, and one machine dying does not take you down.
- Cons: more moving parts. You now deal with network failures, data consistency and deployment across many nodes.
Make servers stateless
Scaling out only works smoothly if any server can handle any request. That means no user session stored in one server's memory. Keep state in a shared store (database, Redis) or in a signed token, so a request can land anywhere.
Where it breaks first
Application servers are easy to multiply. The database usually is not. Reads can be spread with caches and replicas (see the caching and replication parts), and writes eventually need sharding. Always find the real bottleneck with measurements before adding machines.
A sensible order
- Measure. Find the slowest part.
- Optimise queries and add indexes.
- Scale up if it is cheap.
- Add a cache, then more app servers.
- Add read replicas, and only much later, sharding.
Takeaway: start simple, scale up first, design stateless so you can scale out later, and expect the database to be the hard part.
Part 1 of 15 in the System Design series.
