Vertical vs Horizontal Scaling

When your app starts getting real traffic, you hit the first real question in system design: how do you handle more load? There are really only two answers. You either make your existing machine bigger, or you add more machines. That's vertical scaling and horizontal scaling in a nutshell.

Vertical Scaling (Scale Up)

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Vertical scaling (scale up) makes your existing machine more powerful — more CPU cores, more RAM, faster NVMe storage. All traffic still hits one server. The advantages are real: zero code changes, no distributed systems complexity, and it works immediately. Many companies run surprisingly large workloads on a single well-tuned server. But there are two unavoidable problems. First, there's a hard physical ceiling — at some point you've bought the biggest instance AWS offers and you can't go further. Second, you have a single point of failure: if that one server crashes, your entire service is down. Vertical scaling is a valid first move, but it's not a long-term strategy for systems that need to keep growing or provide high availability.

1 / 10.5×1×2×3×Playground

Vertical scaling — single server SPOF, hard ceiling

Vertical scaling means upgrading the machine your service runs on. More CPU cores, more RAM, faster disks, better network cards. Your application doesn't change at all — it just has more resources to work with.

Think of it like upgrading from a Toyota Corolla to an 18-wheeler. Same driver, same road, but the truck can carry a lot more.

Why teams reach for vertical scaling first:

• Zero code changes required
• No distributed systems complexity
• Works immediately
• Simple to reason about

And it genuinely works — for a while. A lot of early-stage companies (and some surprisingly large ones) run entirely on a single beefy server.

The Wall You Eventually Hit

Here's the problem: there's a physical ceiling. At some point, AWS doesn't offer a bigger instance. You can't buy a machine with 10 TB of RAM. The most powerful single-server setups in the world still have hard limits, and you will reach them if you're lucky enough to grow fast.

There's also the cost curve. Doubling a machine's specs rarely doubles the price — it often costs 4-10x more. And you still have a single point of failure. If that one powerful machine goes down, everything goes down.

Horizontal Scaling (Scale Out)

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Horizontal scaling (scale out) adds more machines and distributes load across them with a load balancer. Instead of one big server, you have a fleet of ordinary commodity servers. Losing one node removes it from the load balancer pool — other nodes keep serving. This is how every large internet company operates. The critical prerequisite: your application servers must be stateless. If any user session or in-memory state lives on a specific server, the next request routed to a different server will fail. The solution is externalizing all state: sessions go into Redis, files go into object storage, user data goes into a shared database. Once your servers hold no state, they become interchangeable — you can spin up 50 of them, any one can handle any request, and the system scales horizontally without limit.

1 / 10.5×1×2×3×Playground

Horizontal scaling — fleet, load balancer, external Redis state

Horizontal scaling means adding more machines and distributing the load across them. Instead of one powerful server, you have ten (or a hundred) ordinary servers working in parallel.

This is how every major internet company operates at scale. Netflix doesn't run on one giant server — it runs on tens of thousands of nodes across multiple AWS regions. Google's search index is spread across an almost incomprehensible number of machines.

What horizontal scaling buys you:

• Near-infinite scale (just add more nodes)
• Fault tolerance — losing one node doesn't kill the system
• Cost-effective — commodity hardware is cheap
• Geographic distribution — run nodes close to users

Statelessness: The Hidden Prerequisite

Here's the catch that trips people up: horizontal scaling only works if your service is stateless.

If your server stores any user-specific data in memory — active sessions, user context, in-progress work — then routing a user's second request to a different server breaks everything. That second server doesn't know who they are.

For horizontal scaling to work, every server must be able to handle any request equally. That means:

• Sessions get stored externally (Redis, a database)
• Uploaded files go to shared blob storage (S3, GCS), not local disk
• Application state lives in a database, not in-memory

Once you've pushed state out of your application servers, they become interchangeable. Now you can spin up 50 of them behind a load balancer and it just works.

YouTube's Journey

YouTube is a textbook case of this transition. In its early days (2005-2006), the team scaled vertically as fast as they could. Bigger servers, more RAM, faster MySQL instances. It was fast to execute and good enough to handle the initial growth.

But as the site exploded in popularity, they hit the limits. No single machine could ingest, transcode, and serve millions of videos. They had to make the painful transition to a distributed architecture — sharding their databases, distributing video processing across worker fleets, and serving content through CDNs globally.

The lesson isn't that vertical scaling is bad. It's that vertical scaling buys you time, but horizontal scaling is where you end up if you succeed.

Rule of thumb: Start vertical, plan for horizontal. Don't over-engineer before you need to, but don't paint yourself into a corner with stateful application servers.

Which One Do You Actually Need?

Most applications never outgrow a single well-tuned server. Before you build a distributed system, ask:

• Can a bigger machine solve this for the next 12-18 months?
• Is the cost of that machine acceptable?
• Do we have the engineering bandwidth to maintain a distributed system?

If yes, scale up. Save horizontal scaling for when you genuinely need it.

When you do need horizontal scaling, the architectural work is mostly in making your application stateless and putting the right load balancing in front of it. The servers themselves are the easy part.

Summary

Vertical scaling (scale up) makes a single machine more powerful. It's simple, requires no code changes, but has a hard ceiling and leaves you with a single point of failure. Horizontal scaling (scale out) adds more machines to share the load — it's how large systems handle massive traffic, but it requires stateless application design. Most systems start vertical and move horizontal as they grow. The key prerequisite for going horizontal is externalizing all state out of your application servers.