Horizontal Scaling

Horizontal scaling changes the number of resources serving a workload rather than changing the size of an individual resource. Adding resources is called scaling out; removing them is called scaling in. For example, a web application might expand from two application servers to six during a busy period, then return to two when traffic decreases. Vertical scaling, by contrast, changes the CPU, memory, or other capacity of an individual server.

In cloud environments, horizontal scaling commonly uses virtual machines, container tasks, or managed execution environments. A load balancer distributes incoming requests across available application instances. For background processing, multiple workers can consume jobs from a shared queue without requiring a request-routing load balancer. Each additional resource contributes useful capacity only when the workload can be divided among resources.

Auto scaling provides elasticity by automatically adjusting capacity to changing demand. Scaling policies can respond to measurements such as CPU utilization, requests per target, or queue backlog per worker. Scheduled scaling can prepare capacity for predictable traffic patterns. In AWS, Amazon EC2 Auto Scaling can change the number of EC2 instances in an Auto Scaling group within configured limits. For certification questions, distinguish scalability, the ability to handle changing workload, from elasticity, the adjustment of provisioned capacity to match demand.

Applications scale more easily when individual processing instances do not hold essential local state. A shopping application can store its cart data in a shared data store so that any application instance can handle the next request. Keeping sessions or uploaded files only on one instance creates routing dependencies and risks losing data when that instance is removed. Stateful systems can also scale horizontally, but may require replication, partitioning, and explicit consistency decisions.

Scaling is not instantaneous. New resources need time to start, initialize dependencies, and pass readiness checks before accepting work. Engineers should configure minimum and maximum capacity, appropriate scaling metrics, and instance warmup behavior. During scale-in, connection draining and graceful shutdown help avoid interrupting requests or abandoning jobs. Queue workers should tolerate retries and use idempotent processing where duplicate delivery is possible.

More application instances do not automatically produce proportional performance gains. A shared database, external API rate limit, network constraint, or serialized operation may remain the bottleneck. Horizontal scaling also adds costs and operational complexity, including monitoring, distributed tracing, and coordination. Scaling in can reduce usage-based charges, but not every associated cost disappears when compute resources are removed.

Horizontal scaling is not synonymous with automatic scaling or high availability. Engineers can add instances manually, and multiple instances can still share one failure domain. Distributing capacity across independent failure domains improves resilience, while auto scaling can restore or adjust capacity. A load balancer distributes traffic but does not, by itself, create additional application instances.