Load Balancing

Load balancing separates the address clients use to reach an application from the individual resources that process its traffic. Instead of connecting directly to one server, clients connect to a load-balancing endpoint. The load balancer selects an eligible target using a configured algorithm or routing policy. Depending on the implementation, it can distribute individual requests, connections, or network flows. Its main purposes are to spread demand, improve resource utilization, and support application availability.

For example, an online store might run its application on several virtual machines across two availability zones. A load balancer directs customer traffic across those machines. If one machine fails its health checks, the load balancer normally stops selecting it for new traffic while other healthy machines continue serving requests. This reduces dependence on any single application instance. However, an existing connection to a failed machine can still break, and users may need to retry their requests.

Load balancers operate at different protocol layers. A transport-layer load balancer commonly routes TCP or UDP flows using connection information without interpreting application URLs. An application-layer load balancer understands protocols such as HTTP and can route requests according to the hostname, URL path, or other request attributes. For example, requests for /images can go to an image service while requests for /checkout go to a separate application pool. The correct choice depends on protocol support, routing requirements, connection behavior, and performance needs.

In cloud environments, load balancing commonly works with automatic scaling. A scaling system adds or removes application resources, while the load balancer distributes traffic among the registered, eligible targets. These are separate responsibilities: a load balancer does not launch more servers merely because existing servers are overloaded. Similarly, adding servers will not help unless they become reachable, pass appropriate health checks, and are registered to receive traffic.

Health checks must reflect whether a target can serve useful requests. A successful network connection may prove that a process is listening without proving that its application is working. Conversely, an unnecessarily broad health check can remove every target when a shared dependency experiences a brief problem. Failure handling also varies by implementation; some load balancers can route to unhealthy targets when every target is unhealthy. Health checks therefore support resilience but do not guarantee uninterrupted service.

Application design affects how effectively traffic can be distributed. Keeping session data in a shared store allows successive requests to reach different instances. Session affinity, sometimes called sticky sessions, can keep a user associated with one target, but may produce uneven utilization and does not preserve that target's local state after failure. Connection draining allows in-flight work time to finish before a target is removed during maintenance or scaling.

Load balancing adds cost, configuration, and another network component to troubleshoot. TLS termination can centralize certificate handling, but encryption from the load balancer to backend targets requires separate configuration. Balanced traffic also does not necessarily mean equal traffic: target weights, long-lived connections, and differences in request duration can produce unequal workloads. Monitor application latency, errors, connection counts, and target utilization rather than assuming equal request counts indicate success.

For foundational certification questions, associate load balancers with distributing incoming traffic and improving availability across multiple targets. Distinguish that purpose from automatic scaling, which changes capacity, and DNS resolution, which maps names to endpoints. A highly available design also needs redundant load-balancing infrastructure, sufficient healthy backend capacity, and resilient application dependencies; placing one server behind a load balancer does not make the entire application highly available.