Vertical vs Horizontal Scaling
Make one machine bigger, or add more machines — the first decision in every scaling story.
Vertical scaling (scale up) gives a single server more CPU, memory or faster disks. It needs no code changes, but it has a ceiling and a single point of failure.
Horizontal scaling (scale out) adds more servers behind a load balancer. It has almost no ceiling and survives individual failures, but the application must be stateless or share state through a cache or database.
Diagram
Key concepts
- Stateless service
- Keeps no user session in local memory, so any instance can handle any request.
- Autoscaling
- Adds or removes instances based on metrics such as CPU, request rate or queue length.
- Single point of failure
- A component whose failure takes down the system. One big server is one.
- Elasticity
- Scaling with demand in both directions, so you only pay for what you use.
Trade-offs
Benefits
- Vertical: zero code changes, simple operations
- Horizontal: near-unlimited capacity and built-in redundancy
- Horizontal: rolling deployments with no downtime
Costs
- Vertical: hardware ceiling, cost grows faster than capacity, downtime to resize
- Horizontal: needs stateless design and shared session storage
- Horizontal: more moving parts to monitor
Use it when
- Scale up first for databases and early-stage apps — it is cheap and fast
- Scale out stateless web and API tiers as traffic grows
Common mistakes
- Storing sessions in server memory, so users are logged out when routed elsewhere
- Scaling the app tier while the database stays the bottleneck
- Autoscaling on CPU for an I/O-bound service
Interview questions
Q1Why is horizontal scaling harder for databases than for web servers?
Databases hold state. Scaling out means replicas (with lag) for reads or sharding (with routing and cross-shard queries) for writes. Stateless web servers can simply be cloned.
Q2How do you make a service stateless?
Move sessions to a distributed cache or signed tokens, store files in object storage instead of local disk, and keep no per-user data in memory between requests.
Q3What metric would you autoscale a queue worker on?
Queue depth or consumer lag, since CPU may stay low while messages pile up.
Related lessons
Scalability & Performance
Load Balancing
Spread traffic across healthy servers so no single machine becomes the bottleneck.
Data & StorageDatabase Scaling & Replication
From one database server to replicas, partitions and shards — in the order you should reach for them.
Scalability & PerformanceCaching Strategies
Keep frequently read data close and fast, and decide carefully how it stays fresh.