Skip to main content
Your photo app is growing: CPU is at ~80% and feeds are loading slower. To gain capacity there are two fundamental approaches — make a single server more powerful (vertical scaling) or run many servers in parallel (horizontal scaling). Each approach has trade-offs in cost, complexity, and reliability.

​
Vertical scaling (scale up)

Vertical scaling means increasing a single machine’s resources: more CPU, more RAM, faster disk. You keep the same application code and simply provision a larger instance.
The image illustrates the concept of vertical scaling, showing how to make a server bigger by adding more CPU, RAM, and a faster disk, with a smartphone interface on the left and server icons on the right.
Pros
  • Simple to implement — no app changes required.
  • Low operational overhead for small-scale apps.
  • Quick to get more capacity by resizing instances.
Example: an unchanged server startup call remains valid.
Drawbacks
  • Hard upper limit: you can only buy the biggest machine available.
  • Diminishing returns: higher tiers often cost disproportionately more for modest gains.
  • Single point of failure: one large server failing takes your whole app down.
The image illustrates a scenario where a single large server failure causes an entire app to go down, depicted by a broken server icon and a mobile app interface showing errors. The text emphasizes "One big server is still one server" and "The whole app is down."
When to use vertical scaling
  • Early stages or prototypes.
  • Predictable workloads that fit within the capacity of a single machine.
  • When minimizing operational complexity is a priority.

​
Horizontal scaling (scale out)

Horizontal scaling runs multiple instances of your app across many smaller servers. Add more machines as traffic grows.
The image illustrates horizontal scaling using multiple small servers, showing that if one server fails, the others continue to function. It has a diagram with an app interface pointing to a grid of servers, with one marked as failed.
Advantages
  • Virtually unlimited capacity by adding instances.
  • Higher availability: no single point of failure.
  • Cost efficiency at scale when using commodity instances or containers.
Operational considerations
  • You need a load balancer to distribute requests across the fleet.
  • Shared state must be externalized (database, object storage, or shared cache) so any instance can serve any request.
  • More complexity: service discovery, orchestration (e.g., Kubernetes), monitoring, and autoscaling policies.
When to use horizontal scaling
  • High and/or unpredictable traffic.
  • Requirements for high availability and fault tolerance.
  • Architectures built around microservices, containers, or distributed systems.

​
At-a-glance comparison

​
Practical rule of thumb

Start with vertical scaling for simplicity and lower initial cost. Move to horizontal scaling when you hit vertical limits, need higher availability, or when traffic grows beyond what a single machine can handle.
For further reading on building resilient, scalable systems, see: Start simple, monitor key metrics (CPU, memory, latency, error rates), and evolve your architecture to match your traffic, availability, and cost requirements.

Watch Video