Vertical Scaling

In the previous page, we saw that ShortLink's traffic keeps growing, and a system needs to handle more load without slowing down. ShortLink still runs on a single server. In this page, we'll try the simplest fix first: make that one server more powerful.

Definition

Vertical scaling means handling more load by giving one machine more power: a faster CPU, more memory (RAM), faster disks, or a faster network.

You don't add more servers. You make the same server bigger.

Think of a small restaurant with one cook. When more customers arrive, you don't hire a second cook. Instead, you give the one cook a bigger stove, a larger kitchen, and sharper knives. Same cook, more capacity.

1Before:  [ Server: 4 CPU, 8 GB RAM ]
2After:   [ Server: 16 CPU, 64 GB RAM ]   ← same server, more power

Because the machine grows "upward" in size, vertical scaling is also called scaling up.

Click to zoom

How Vertical Scaling Works

Here's how it usually goes for ShortLink:

1. Notice the problem. Monitoring shows the server's CPU is at 95% during busy hours, and redirects are getting slow.
2. Pick a bigger machine. In the cloud, you choose a larger server size (often called an instance type). On your own hardware, you add parts or buy a bigger machine.
3. Stop the server (in most cases).
4. Upgrade it. Switch to the bigger size, or install the new hardware.
5. Start it again. ShortLink runs the same code, just on a stronger machine.

Nothing about ShortLink's code changes. The application doesn't even know the machine got bigger. That's what makes vertical scaling so simple.

Scale Up vs. Scale Down

Vertical scaling works in both directions:

• Scale up: move to a bigger machine when you need more power.
• Scale down: move to a smaller machine when you need less, to save money.

Scaling down is easy to forget, but it matters: an oversized server costs money every hour, even when it's sitting idle.

Since both directions usually need a restart, teams don't do this often. You might scale up before a known busy season, and scale down after it, but not every hour.

CPU and RAM Upgrades

The two most common upgrades are CPU and RAM. They fix different problems.

CPU (processing power) helps when the server is busy doing work.

For ShortLink, every request needs some processing: reading the request, looking up the short code, and sending the redirect. More CPU cores mean more requests can be handled at the same time.

RAM (memory) helps when the server needs to keep more data close by.

Reading from RAM is much faster than reading from disk. If ShortLink keeps its most popular links in memory, more RAM means more links can be served without touching the slower disk.

The key idea: upgrade the part that's actually struggling. Doubling the RAM won't help if the CPU is the problem.

A quick example for ShortLink:

1Current server:  handles about 1,000 requests per second
2New traffic:     3,000 requests per second at peak
3 
4If CPU is the bottleneck, and the work spreads evenly across cores:
5  4 cores  →  ~1,000 requests/second
6  16 cores →  up to ~4,000 requests/second   ← enough, with room to spare

That "up to" matters. Real gains are usually a bit lower, as we'll see in the bottlenecks section.

Vertical Scaling in Application Servers

An application server is the server that runs your code. For ShortLink, it's the program that receives "open sl.io/abc123" and replies with "go to the long link".

Vertical scaling works well here, as long as the application can use the extra power:

• More CPU cores only help if the app handles many requests in parallel (using multiple threads or processes). A program that does everything on one thread can only use one core, no matter how many you add.
• More RAM helps the app keep more in memory, like caches and open connections.

Most modern web frameworks handle many requests in parallel, so ShortLink's app server benefits from a bigger machine without code changes.

Vertical Scaling in Databases

ShortLink also has a database that stores every short code and its long link. Databases are where vertical scaling is used the most.

Why? Because splitting a database across many machines is hard. If the data lives on one machine, every query is simple: it's all in one place. Once the data is spread across many machines, you have to decide which data goes where and how to keep it all consistent. (We'll cover that later in this module.)

So the usual first step for a growing database is simple: give it a bigger machine.

• More RAM is often the biggest win. If the most-used data fits in memory, the database rarely has to read from disk.
• Faster disks speed up writing new links and reading data that isn't in memory.
• More CPU helps with many queries running at once.

Many large applications run their main database on one very powerful machine for a long time before splitting it.

Advantages of Vertical Scaling

1. Simple. No code changes. No new servers to coordinate. The same app runs on a bigger machine.

2. No distributed-system problems. With one server, there's no question of which server has which data, or how to keep many copies in sync.

3. Fast to do. In the cloud, it can be a few clicks and a restart.

4. Easy to manage. One machine to monitor, update, and secure.

5. Fast communication. Everything happens inside one machine, so there's no network delay between parts of the system.

For ShortLink at this stage, vertical scaling is exactly the right first move.

Limitations of Vertical Scaling

But vertical scaling can't go on forever.

1. There's a ceiling. Every machine has a maximum size. Even the biggest cloud servers, with hundreds of CPU cores and terabytes of memory, have a limit. Once you're on the largest machine available, you can't scale up anymore.

2. Cost grows fast. Bigger machines cost more, and the very largest ones are especially expensive.

3. Performance doesn't grow evenly. Doubling the hardware rarely doubles the speed.

4. Still one machine. If it fails, everything fails.

5. Upgrades often need downtime. Changing the machine usually means restarting it.

The next sections look at these limits one by one.

Click to zoom

Vertical Scaling Bottlenecks

A bottleneck is the slowest part of a system, the part that limits everything else. Like the narrow neck of a bottle, it controls how fast things can flow.

Upgrading one part often just moves the bottleneck somewhere else:

1Step 1:  CPU is at 100%           → upgrade CPU
2Step 2:  Now RAM is full          → upgrade RAM
3Step 3:  Now the disk is too slow → upgrade disk
4Step 4:  Now the network is maxed → ...

Some bottlenecks can't be fixed with hardware at all:

• Single-threaded code can only use one CPU core, so extra cores sit idle.
• Locks in the app or database make requests wait for each other, no matter how fast the machine is.
• Connection limits in the database cap how many requests can talk to it at once.

This is why doubling the hardware usually gives less than double the performance. Part of the work always waits on something that more hardware doesn't speed up.

Single Point of Failure (SPOF)

A Single Point of Failure (SPOF) is any part of a system that, if it breaks, takes the whole system down.

With vertical scaling, ShortLink still runs on one server. That server is a SPOF:

1Users  →  [ ShortLink Server ]  →  [ Database ]
2                   ✗
3          Server crashes → every short link stops working

It doesn't matter how powerful the server is. A hardware failure, a crash, a power cut, or a bad update brings ShortLink down completely, for every user.

A bigger server handles more traffic, but it isn't more reliable. If anything, more is riding on that one machine.

Downtime During Upgrades

Downtime is the time when the system is unavailable to users.

With only one server, upgrading it usually means:

11. Stop the server       ← ShortLink is down
22. Change the machine    ← ShortLink is down
33. Start the server      ← ShortLink is down until fully started

During those minutes, every user who opens a short link gets an error.

Teams reduce the impact by:

• upgrading during low-traffic hours, like late at night,
• announcing a maintenance window ahead of time,
• testing the new size in advance, so the switch goes smoothly.

But with a single server, you can't avoid downtime completely. That's a problem for a service people rely on every minute of the day.

Cost vs. Performance Trade-offs

At small sizes, vertical scaling is very cost-effective. A modest upgrade often gives a big improvement for a small price.

But as machines get bigger, two things happen:

• Price keeps going up, and the very largest machines can be especially expensive.
• Performance gains get smaller, because of the bottlenecks we just saw.

1Upgrade              Cost     Speed gain
2Small  → Medium      2x       close to 2x     ← great value
3Medium → Large       2x       less than 2x    ← still good
4Large  → Largest     2x+      much less       ← poor value

There's also a hidden cost: if the server is sized for the peak (like a viral spike), you pay for that power all the time, even at 4 AM when traffic is low.

The trade-off: vertical scaling is the cheapest option at first, and becomes the most expensive one as you get bigger.

Real-World Use Cases

Vertical scaling is still the right choice in many situations:

For ShortLink today, it's the perfect fit: a single bigger server handles the growth with almost no effort.

Vertical Scaling vs. Horizontal Scaling

Vertical scaling makes one server bigger. The other option, horizontal scaling, adds more servers that share the work.

Back to the restaurant: vertical scaling gives the one cook a bigger kitchen. Horizontal scaling hires more cooks.

1Vertical:    [ Server ]  →  [  BIGGER SERVER  ]
2 
3Horizontal:  [ Server ]  →  [ Server ] [ Server ] [ Server ]

In practice, most systems use both: scale up first because it's simple, then scale out when you hit the limits.

Summary

1Vertical scaling   →  make one server more powerful (scale up)
2Scale down         →  move to a smaller machine to save money
3CPU / RAM          →  upgrade the part that's actually struggling
4Databases          →  the most common place to scale vertically
5Advantages         →  simple, no code changes, no distributed problems
6Limits             →  hardware ceiling, rising cost, bottlenecks
7SPOF               →  one server fails, everything fails
8Downtime           →  upgrades usually need a restart

ShortLink now runs on a bigger server, and it's handling more traffic. But it's still one machine: it has a ceiling, it goes down during upgrades, and if it fails, every short link breaks. To fix that, we need more than one server, which is horizontal scaling, our next topic.