What is the difference between horizontal and vertical scaling, and when do you choose each?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
Vertical scaling (scale up) adds more CPU/RAM/disk to an existing server — simple but hits a hardware ceiling and has a single point of failure. Horizontal scaling (scale out) adds more machines behind a load balancer — nearly limitless but requires distributed-systems thinking. Start vertical for early simplicity; go horizontal when you outgrow a single box or need fault tolerance.
Detailed explanation
Vertical scaling means upgrading the same machine: more cores, more memory, bigger disk. Pros: no code changes, no data-partitioning complexity, works with any architecture. Cons: hard physical/disk ceiling, downtime to upgrade, and that one server remains a single point of failure — if it dies, the service dies. Cloud instances cap out (e.g., 128 vCPUs), so growth stalls abruptly. Horizontal scaling means adding commodity machines behind a load balancer and treating them as a pool. Pros: near-linear growth, no theoretical ceiling, built-in redundancy (lose a node, traffic reroutes). Cons: requires stateless or externally-stored state, introduces network latency, needs service discovery and load balancing, and forces you to solve data partitioning, consistency, and distributed coordination. Decision framework: go vertical while traffic fits one box and simplicity wins; switch to horizontal when (a) you approach the largest instance size, (b) you need high availability beyond a single machine, or (c) cost-per-request favors many small boxes. Most production web apps are designed horizontal-first because re-architecting a vertical monolith later is painful. Databases often stay vertical longer (or use managed horizontal solutions) because stateful horizontal scaling is harder.
Example
Vertical: upgrading an EC2 t3.medium (2 vCPU, 4 GB) to an r6g.2xlarge (8 vCPU, 64 GB) to handle more traffic on the same app server.
Horizontal: moving from one app server to an Auto Scaling group of 4 t3.medium instances behind an Application Load Balancer, with session state moved to Redis so any node can serve any request.Interview tip
Frame it as a trade-off between simplicity and ceiling. Then name the trigger that forces the switch: hitting the largest instance size or needing fault tolerance. That decision framework is what interviewers listen for.
Common mistakes
- Saying horizontal scaling is always better.
- Not mentioning that stateful horizontal scaling is hard.
- Forgetting the single-point-of-failure argument against vertical scaling.