Horizontal vs Vertical Scaling

The two ways to add capacity: vertical scaling makes one machine bigger — more CPU, more RAM — while horizontal scaling adds more machines behind a load balancer. The choice shapes the whole architecture, because scaling out only works if instances are interchangeable.

Scale up first: it needs no code changes and modern machines are enormous — a bigger database instance solves most early bottlenecks in one move. Scale out when growth outruns any single machine, when you need redundancy (one box is always a single point of failure), or when load is elastic and you want to add and remove capacity with demand.

Vertical is simple but has a hardware ceiling, a reboot-to-resize window, and no fault tolerance. Horizontal is near-limitless and resilient but demands stateless services, externalised sessions, a shared data tier — and brings distributed-systems problems (consistency, discovery) that one machine never had.

Design services stateless from the start — state in the database, sessions in Redis — so scaling out is an option even while you scale up. Put instances behind a load balancer with health checks, autoscale on a real signal (CPU, queue depth, latency), and remember databases scale out differently: replicas for reads, sharding only when truly forced.