Horizontal and Vertical Scaling: A Practical Introduction for Web Apps

Vertical scaling: strengths and ceilings

Lift-and-shift workloads love vertical scaling: fewer moving parts, easier debugging, classic backup/restore mental model.

Single-node databases eventually max out; failover to a passive replica is still “two boxes,” not elastic infinity.

Horizontal scaling: what must become stateless

HTTP sessions on local disk break when traffic moves between nodes—use sticky sessions deliberately or externalize sessions to Redis/database.

File uploads cannot assume a local path unless you sync or use shared/object storage from day one.

Load balancers and health checks

• Health checks should validate dependency depth (can your app reach DB?), not only TCP :80 open.
• Graceful shutdown hooks drain connections before SIGKILL during deploys.
• Watch asymmetric routing: one bad node in the pool poisons user trust if retries are blind.

The database is usually the hard part

Sharding and multi-primary setups are advanced; many teams first scale reads with replicas and cache hot keys—understand replication lag before serving user-specific reads from replicas.

Eventual consistency is a product decision, not only an infrastructure knob.