Designbench

Lesson 1.3 · 10 min

Scaling: up or out

Push traffic until one big machine hits its ceiling, then scale out and fix the three things that break.

The idea in plain words

When one shop gets too busy you can either move to a bigger shop or open more shops. Servers are the same: buy a bigger machine, or add more machines and share the work.

The problem it solves

When traffic grows, one server eventually can’t keep up. You need a way to add capacity without rewriting the system each time.

How it works

  1. Scaling up: move to a bigger machine. Nothing in the code changes.
  2. Bigger machines cost more per unit of power and there is a biggest one you can buy.
  3. Scaling out: run several identical servers behind a load balancer.
  4. For that to work, servers must not keep user data in memory: sessions go to a shared store, files to object storage.
  5. Then you can add or remove servers freely, and one dying doesn’t take the site down.

Example

A shop’s single server handles 500 requests per second and peak is now 1,500. Doubling the machine buys some time; three servers behind a load balancer handle 1,500 and survive one crash. Black Friday at 5,000? Add more servers for the day.

Key terms

Scale up (vertical)
Give one machine more CPU, memory or disk.
Scale out (horizontal)
Add more machines and spread the work across them.
Ceiling
The biggest machine you can buy; past it, scaling up stops working.
Stateless
A server that keeps no user data between requests, so you can add or remove copies freely.
Single point of failure
One part whose failure takes the whole system down.

In this lesson you'll learn

Sections

  1. Push the traffic
  2. Ready to scale out?
  3. Check yourself

Cheat sheet

Scale upsimple, has a ceiling
Scale outno ceiling, needs stateless apps
One big boxsingle point of failure
Before scaling outsessions, files, health checks
Good answerstart up, scale out at X

The interactive simulations and the quiz load with JavaScript.