Scaling Up vs Scaling Out

Simplicity and a ceiling, against no ceiling and more moving parts.

Scaling up buys capacity with a bigger machine and keeps the system simple, until the largest machine is reached. Scaling out buys capacity with more machines and has no fixed ceiling, at the price of more parts to run. The part being scaled, the shape of the load and the size of the team decide which comes first.

Scaling up and scaling out on four axes
Axis	Scaling up	Scaling out
Ceiling	The largest machine on offer	None fixed; add another copy
Failure	Still one machine; it fails as a whole	One copy fails, the rest carry on
Complexity	No code change, nothing new to operate	State must move out; more machines to run
Cost curve	Each step about doubles the price	Grows in small steps, one copy at a time

Scaling up

Use it when

The part holds state that is hard to split, such as a database taking writes
A larger machine exists and the team is small
The load is growing steadily, not leaping

Avoid it when

The largest machine is already in use, or close to it
One machine failing would take the system down and no standby exists

Scaling out

Use it when

The part is stateless, such as application servers
Load swings widely through the day, so copies can come and go
Losing one machine must not be noticed

Avoid it when

State still lives in each server's memory
Splitting the part needs work the team cannot yet carry, as sharding a database does

A worked choice. A single relational database is at 80% CPU from writes, and the team has two engineers. A bigger machine is the next step: one setting, no new parts. Read copies would not help, because the load is writes, and sharding, splitting the data across databases, is a project the team cannot yet carry.

So scale stateless parts out and stateful parts up first, and move a stateful part out only when the largest machine, or the need for a spare, forces it.

← → move through sections and cards