Scalability is a system’s ability to handle growing load by adding resources — either by using a bigger machine (vertical scaling) or by adding more machines (horizontal scaling).1
Overview
Vertical scaling, or scaling up, means giving one server more CPU, memory, or faster disks. It is simple but bounded by the largest machine you can buy and leaves a single point of failure. Horizontal scaling, or scaling out, means running many servers behind a load balancer and dividing the work among them.
Scaling out has no hard ceiling and pairs naturally with redundancy, but the software must be designed for it — stateless services and shared data stores scale out far more easily than monoliths that keep session state in local memory. Elasticity is the related ability to add and remove capacity automatically as demand changes, adding servers under load and releasing them when the spike passes.
Trade-offs
The two directions have opposite strengths, and real systems often scale up first, then out:
| Aspect | Scale up (vertical) | Scale out (horizontal) |
|---|---|---|
| How | Bigger single machine | More machines |
| Ceiling | Largest box available | Effectively none |
| Complexity | Low | Higher (distribution) |
| Fault tolerance | Single point of failure | Survives node loss |
| App requirement | Runs as-is | Must be stateless-friendly |
Scaling up is the quick win for a single overloaded server; scaling out is what carries a system past the limits of any one machine — and, done right, improves availability along the way.
Where it fits
Scalability is about handling more, while high availability is about staying up; horizontal scaling tends to deliver both. Cloud computing, Kubernetes, and serverless computing all exist largely to make scaling out routine. GopherTrunk scales horizontally in a natural way: cover more sites by adding capture nodes, each decoding its own RF and feeding a shared back end.
Sources
-
Scalability — Wikipedia, on vertical and horizontal scaling and elasticity. ↩