Vertical vs horizontal scaling

The shop is full - now what?

Your website got popular. The crowd slider from last lesson is pinned to the right, and one of the four parts is permanently full. Congratulations - and welcome to the oldest question in system design.

You have exactly two options, and every company on Earth has faced this exact choice. Option one: replace your shop with a BIGGER shop - stronger brain, bigger desk, faster notebook. That's called scaling UP (or 'vertical scaling'). Option two: keep the shop the same size, but open MORE shops - two, then five, then fifty. That's called scaling OUT (or 'horizontal scaling').

Neither one is 'correct'. They're trade-offs, and knowing when to use which is the actual skill.

Scaling up: the move nobody brags about

Scaling up is beautifully boring. You swap the machine for a bigger one and... that's it. Nothing about your website changes. No new moving parts, no new ways for things to break. For databases especially, one big machine beats a team of small ones for a very long time.

But it has two hard limits. First, the price curve is cruel: a machine twice as powerful costs much MORE than twice as much, and eventually there simply isn't a bigger machine to buy. Second - and this is the killer - it's still ONE machine. One power cable. One thing that can break. When it breaks (and one day it will), your entire website is gone until it's fixed.

Try both - then break something

The widget below lets you play both strategies. Here's the experiment that matters: pick a strategy, then press the skull button to break one machine. Watch what your customers experience in each case. This one difference is why every big website you use is built on MANY machines.

Scaling out: the second shop changes everything

So more machines means surviving failures. Great - but the day you open shop number two, three brand-new problems appear that never existed before. This is the real price of scaling out, and it's paid in headaches, not money.

Problem 1: who serves which customer? Someone has to stand at the street corner directing people - 'you go to shop A, you go to shop B'. On the internet that's a load balancer, and it's the whole next lesson.

Problem 2: the worker no longer remembers you. In shop A the worker knows your order. Your next visit lands in shop B, where nobody's ever seen you. On websites this is the login problem: if 'who is logged in' lives inside one server's memory, users get mysteriously logged out whenever they land on the other server.

Problem 3: where's the REAL notebook? If both shops keep their own notebooks, they instantly disagree - shop A thinks you bought socks, shop B has never heard of you. Two notebooks that disagree isn't a system; it's an argument.

The one rule that fixes all three

Here's the trick the whole industry settled on, and it's worth memorizing because it quietly runs the modern internet: make the workers forgetful ON PURPOSE, and keep ONE shared notebook in the back room that every shop uses.

In computer words: keep the app servers stateless - meaning any server can handle any request, because no server keeps anything important in its own head - and store everything that matters (logins, orders, data) in ONE shared place: the database.

Why is this so powerful? Forgetful workers are interchangeable. Need more capacity? Hire another - it can start instantly, since there's nothing to teach it. One quits mid-shift? Nobody's order is lost, it's all in the shared notebook. Every question about 'how do I scale this?' becomes easy when the workers are forgetful.

The shared notebook itself eventually becomes the crowded shop, of course. That's module 2.