Topic 9.1
Vertical Scaling
In one line
Bigger machine: more CPU, RAM, disk, network. Simple, finite, and expensive in all the interesting ways.
Think of it like this
Upgrading from a small kitchen stove to a giant commercial one to cook faster. It helps, but there's still only ONE stove — if it breaks, the whole kitchen stops cooking.
Key ideas
- 01
Up-size the node — no architecture change, no code change (usually).
- 02
Ceiling: a single machine maxes out; some components are simply not sold beyond a size.
- 03
Cost curve: big machines cost super-linearly — 2x CPU costs 4x money for 1.5x throughput.
- 04
Single point of failure: vertical still equals ONE node — the machine dies, everything dies.
- 05
When right: early stage, latency-sensitive single-writer workloads (a primary DB), compliance simplicity.
- 06
Interview: 'we vertical-scale the primary to the size the write path needs, then horizontal-scale the reads'.
Java / Spring map
- →
JVM tuning benefits from vertical RAM; heap size drives GC behavior (pause issues at huge heaps).
Code & diagrams
The picture that explains why 'just get a bigger machine' eventually stops working.
Explain without notes
Why does a 64-core machine still have a single point of failure?
Practice
Draw the cost-vs-capacity curve and mark where the architecture conversation starts.
Trade-offs
- ↔
Simple + fast vs finite + single-failure + expensive.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I use vertical scaling for the right reasons and say its ceiling out loud.