Horizontal vs Vertical Scaling

Objectives

By the end of this lesson, you should be able to:

• Distinguish horizontal scaling from vertical scaling
• Explain a real limit of vertical scaling
• Explain why horizontal scaling introduces a new problem vertical scaling doesn’t have

💡 Why this matters: Module 2’s cluster module ran multiple worker processes on one machine. This module takes the same idea further, across multiple machines entirely, this is what “scaling” usually means for a real, growing application, and it introduces a genuinely new problem, covered in the next lesson, that running more processes on one machine doesn’t.

Vertical Scaling

Vertical scaling means making a single instance bigger, more CPU, more memory, a faster disk, the application itself doesn’t change at all, it’s simply given more resources to work with. This is often the simplest first step, no architectural changes needed, just a bigger server, but it has a hard ceiling, there’s a largest machine available, from any provider, and a diminishing return well before that ceiling, doubling a machine’s resources rarely doubles what it can actually handle.

Horizontal Scaling

Horizontal scaling means running more instances, instead of one bigger server, several ordinary ones, each handling a share of the total traffic, this is what Module 2’s cluster module did on a single machine, and what this module extends across multiple, separate machines entirely. There’s no hard ceiling the same way vertical scaling has, adding another instance is usually possible, whether there are already two or two hundred.

The New Problem Horizontal Scaling Introduces

A single instance, or several worker processes sharing one machine’s memory (Module 2), can keep information in local memory and rely on it being there for the next request. Multiple, separate instances can’t, a request handled by instance A has no access to whatever instance B happens to be holding in its own memory, this sounds abstract until it breaks something concrete, the next lesson demonstrates exactly that, with a real, working example.

Why This Matters for This Track Specifically

Every application this track has built assumes, implicitly, that “the server” is one thing, one process, one machine, remembering things between requests. The moment there’s more than one instance, that assumption needs to be checked, deliberately, for every piece of state the application relies on, session data (Course 3, Module 2), rate-limit counters (Course 3, Module 6), anything held only in a single process’s memory, is a candidate for breaking the moment a second instance joins.

Try It

1. Explain, in your own words, the ceiling vertical scaling eventually runs into, that horizontal scaling doesn’t have.
2. List two pieces of state this track’s Notes API relies on, and guess, before the next lesson confirms it, whether each would survive being handled by a different instance on the very next request.
3. Explain, in one or two sentences, why “just add more servers” isn’t actually the whole story, once an application’s own code makes assumptions about staying on one instance.

Recap

• Vertical scaling makes one instance bigger, simple, but with a real, low ceiling, horizontal scaling runs more instances, with no equivalent hard limit.
• Horizontal scaling introduces a new problem vertical scaling never has, state held in one instance’s memory isn’t visible to any other instance.
• Every piece of state an application relies on needs to be checked against this assumption before it’s safe to run more than one instance.

Next lesson: statelessness, demonstrating exactly what breaks when session state lives only in one instance’s memory, and why Course 3’s JWTs don’t have the same problem.