Horizontal Scaling

When a web application gets more traffic than one server can handle, you can run it on two servers, then ten, with a load balancer sharing requests between them. Each server does the same job on a different part of the load. Cloud platforms make this easy: autoscaling groups and Kubernetes add and remove instances automatically as traffic rises and falls.

Scaling out has big advantages. Capacity can grow almost without limit, a single machine failing doesn't take the service down, upgrades can roll through instances one at a time without downtime, and many small machines can be cheaper than one giant one. Large internet services run on thousands of commodity servers for exactly these reasons.

It does require the right design. Application servers should be stateless, keeping sessions, uploads and caches in shared services such as Redis or object storage, so any instance can handle any request. Databases are harder to scale out: read replicas spread reads, but spreading writes means sharding the data, which complicates queries, transactions and operations.

A common misconception is that adding servers always adds speed. Shared bottlenecks, such as a single database, a lock or a slow external API, cap throughput no matter how many app servers you add, and coordination between nodes adds its own overhead. Measure where the bottleneck is before scaling out.