Scaling: horizontal, vertical, and what you actually need
Two directions
Vertical: a bigger machine. Fast to apply, capped, and a single point of failure.
Horizontal: more instances behind a load balancer. Requires the app to be stateless — sessions in a shared store, files in object storage, and no reliance on local memory.
Where you actually get stuck
Database connections, queries without an index, locks, and long synchronous processes. Doubling servers when the bottleneck is the database only increases the pressure.
So: profile before scaling. Half an hour of measurement saves a month of needless architecture.
Reads versus writes
Most systems read far more than they write. Read replicas, caching and materialized views go a long way before a real data split is needed.
Going deeper
Auto-scaling needs a leading metric, not a lagging one: queue length or request rate respond earlier than CPU utilization. And set an upper cap — unbounded auto-scaling turns a loop bug into a surprise invoice.