When would you choose vertical scaling over horizontal scaling?
Choose vertical scaling when the system is small, stateful, or hard to split, such as a single relational database. It is simple and fast to do, but it has a hardware ceiling and leaves one machine as a single point of failure.
Explain it simply
Vertical scaling means buying a bigger machine: more CPU, RAM, faster disk. Horizontal scaling means adding more machines. Horizontal gets the glory, but vertical is often the right first move.
Reasons to go vertical:
- No code change. The app runs exactly as before, just faster.
- State is easy. A database on one machine needs no sharding, no distributed transactions, no cross-node joins.
- Operations are simple. One server to patch and monitor.
Limits: the biggest machine has a ceiling, price rises faster than capacity at the top end, and a restart or crash takes everything down.
Go horizontal when you need fault tolerance, when load exceeds the largest affordable box, or when the workload is stateless and trivially duplicated, like web servers behind a load balancer.
Example
A college admissions portal runs on one 4 GB database server and slows during results day.
Option A: upgrade to a 32 GB server -> done in an evening, no code change.
Option B: shard across 5 servers -> weeks of work, joins break,
every query needs routing logic.For a modest workload, A is clearly cheaper. Revisit B only when A stops being enough.
What to say in the interview
"I start vertical because it is simple and keeps data on one node, especially for the database. I move horizontal when I hit the hardware or cost ceiling, need redundancy, or the tier is stateless and easy to replicate. Most real systems use vertical for the database and horizontal for the app tier."