Back to blog
This post is on the way.
Reading
post
The piece is being set. The cover and the first lines land here.
Back to blog
This post is on the way.
Reading
post
The piece is being set. The cover and the first lines land here.
Back to blog
Reading
The piece is being set. The cover and the first lines land here.
Back to blog
Reading
The piece is being set. The cover and the first lines land here.
Back to blog
Reading
The piece is being set. The cover and the first lines land here.
23 Feb 2026 · Zoro · scaling · Infrastructure · devops
Scaling is one of the most misunderstood concepts in infrastructure.
Many developers hear terms like vertical scaling and horizontal scaling but rarely see what they actually mean in production systems.
This post breaks it down clearly, using real-world production examples, trade-offs, and architectural consequences.
No theory. No vendor bias. Just how scaling really works.
There are only two ways to increase system capacity:
That’s it.
Everything else is a variation of these two strategies.
Vertical scaling means increasing the resources of a single server.
For example:
The architecture stays the same. The machine just becomes stronger.
You run a web app on:
Traffic increases.
Instead of redesigning anything, you upgrade to:
The app now handles more traffic.
Simple.
For early-stage systems, this is ideal.
There is always a ceiling.
You cannot scale infinitely on one machine.
Eventually:
If that one machine crashes, everything goes down.
This is the key limitation.
Horizontal scaling means adding more servers instead of making one server bigger.
Instead of:
One big machine
You move to:
Multiple smaller machines working together.
You have one server handling 1,000 requests per second.
Traffic increases to 5,000 requests per second.
Instead of upgrading one machine, you deploy:
5 servers behind a load balancer.
Each server handles part of the traffic.
Horizontal scaling requires:
You move from single-machine thinking to distributed system thinking.
In real production environments, horizontal scaling introduces new complexities:
If users log in, where is session data stored?
If sessions are stored in memory on one server, requests must always hit that same server.
That breaks horizontal scaling.
Solution:
Even if you scale application servers horizontally, the database may still be a single point of failure.
True horizontal scaling requires:
Scaling is not just adding web servers.
With one server:
If it fails, system is down.
With multiple servers:
If one fails, traffic shifts.
This reduces blast radius.
Horizontal scaling increases resilience when designed correctly.
Vertical scaling:
Horizontal scaling:
At small scale, vertical scaling is cheaper.
At large scale, horizontal scaling is more efficient.
Vertical scaling is ideal when:
It is not wrong. It is appropriate for many systems.
Horizontal scaling becomes necessary when:
This is where distributed architecture becomes unavoidable.
Running multiple containers on the same server is not horizontal scaling.
If all containers share the same machine:
If that machine dies, everything dies.
That is still vertical scaling.
True horizontal scaling means separate machines.
Most production systems use both.
Example:
This combines:
This is common in serious production systems.
Most systems evolve like this:
Stage 1: Single small server
Stage 2: Larger single server
Stage 3: Multiple servers behind load balancer
Stage 4: Distributed database and services
Stage 5: Region-level distribution
Scaling is evolutionary, not immediate.
Scaling is not about buzzwords.
It is about understanding:
Vertical scaling buys simplicity.
Horizontal scaling buys resilience.
The right choice depends on stage, load, and operational maturity.
Understanding the trade-offs is what turns infrastructure from reactive to intentional.
23 Feb 2026 · Zoro · scaling · Infrastructure · devops
Scaling is one of the most misunderstood concepts in infrastructure.
Many developers hear terms like vertical scaling and horizontal scaling but rarely see what they actually mean in production systems.
This post breaks it down clearly, using real-world production examples, trade-offs, and architectural consequences.
No theory. No vendor bias. Just how scaling really works.
There are only two ways to increase system capacity:
That’s it.
Everything else is a variation of these two strategies.
Vertical scaling means increasing the resources of a single server.
For example:
The architecture stays the same. The machine just becomes stronger.
You run a web app on:
Traffic increases.
Instead of redesigning anything, you upgrade to:
The app now handles more traffic.
Simple.
For early-stage systems, this is ideal.
There is always a ceiling.
You cannot scale infinitely on one machine.
Eventually:
If that one machine crashes, everything goes down.
This is the key limitation.
Horizontal scaling means adding more servers instead of making one server bigger.
Instead of:
One big machine
You move to:
Multiple smaller machines working together.
You have one server handling 1,000 requests per second.
Traffic increases to 5,000 requests per second.
Instead of upgrading one machine, you deploy:
5 servers behind a load balancer.
Each server handles part of the traffic.
Horizontal scaling requires:
You move from single-machine thinking to distributed system thinking.
In real production environments, horizontal scaling introduces new complexities:
If users log in, where is session data stored?
If sessions are stored in memory on one server, requests must always hit that same server.
That breaks horizontal scaling.
Solution:
Even if you scale application servers horizontally, the database may still be a single point of failure.
True horizontal scaling requires:
Scaling is not just adding web servers.
With one server:
If it fails, system is down.
With multiple servers:
If one fails, traffic shifts.
This reduces blast radius.
Horizontal scaling increases resilience when designed correctly.
Vertical scaling:
Horizontal scaling:
At small scale, vertical scaling is cheaper.
At large scale, horizontal scaling is more efficient.
Vertical scaling is ideal when:
It is not wrong. It is appropriate for many systems.
Horizontal scaling becomes necessary when:
This is where distributed architecture becomes unavoidable.
Running multiple containers on the same server is not horizontal scaling.
If all containers share the same machine:
If that machine dies, everything dies.
That is still vertical scaling.
True horizontal scaling means separate machines.
Most production systems use both.
Example:
This combines:
This is common in serious production systems.
Most systems evolve like this:
Stage 1: Single small server
Stage 2: Larger single server
Stage 3: Multiple servers behind load balancer
Stage 4: Distributed database and services
Stage 5: Region-level distribution
Scaling is evolutionary, not immediate.
Scaling is not about buzzwords.
It is about understanding:
Vertical scaling buys simplicity.
Horizontal scaling buys resilience.
The right choice depends on stage, load, and operational maturity.
Understanding the trade-offs is what turns infrastructure from reactive to intentional.