Back to roadmap
Module 2 · Scale, Latency, CapacityDay 01120 min

Vertical vs Horizontal Scaling

Bigger box vs more boxes.

← PreviousNext →
Day 011

Vertical vs Horizontal Scaling

1× big
service
S
service
S
service
S
service
S
service
Signal path
Vertical (taller) vs horizontal (wider) scaling
LB
edge
flow
S
service
LB
edge
flow
S
service
LB
edge
flow
S
service
Memory hook

Vertical vs Horizontal Scaling: bigger box vs more boxes

Mental model

make the invisible limits visible

Design lens

Vertical: simple, finite ceiling.

Recall anchors
VerticalHorizontal

Why it matters

Vertical scaling buys a bigger machine; horizontal scaling adds more machines. Vertical is fast and simple but caps at the largest single box. Horizontal is unbounded but only works when work can be split across machines without a global coordinator.

Deep dive

Vertical limits: physics (single CPU socket), price curves (top-tier instances are non-linearly expensive), and blast radius (one machine = one failure domain).

Horizontal demands: stateless app servers (any can handle any request) or partitioned state (each machine owns a slice). Achieving statelessness usually means moving session, cache, and locks out of the process.

A common path: scale up first (cheap and easy), then scale out when the largest single instance is no longer enough.

Demo / scenario

Single API server hitting 80% CPU at peak.

  1. Option A: upgrade to 2x CPU instance — 30 min, no code change.
  2. Option B: front with LB, run 4 stateless instances behind it.
  3. Option B requires moving sessions to Redis or JWT.
  4. Both buy headroom; B is the durable choice.

Tradeoffs

  • Vertical: simple, finite ceiling.
  • Horizontal: complex, ~unbounded ceiling.
  • Mixing both is normal: small fleets of medium boxes.

Diagram

1× big
S
S
S
S
LB
Vertical (taller) vs horizontal (wider) scaling.

Mind map

Check yourself

Loading quiz…

Sources & further reading

← PreviousNext →