Strategien für den Load Balancing

Once you scale horizontally, you have many identical servers. But how do clients know which one to hit? A load balancer sits in front of your servers and spreads incoming requests across them.

• Prevents any single server from being overwhelmed
• Enables seamless scaling up and down
• Improves availability if one server fails

A load balancer is a reverse proxy: clients connect to one address, and the balancer forwards the request to a healthy backend. The client never sees the internal topology.

This indirection is what makes adding or removing servers invisible to users.

Round robin is the simplest algorithm: requests are handed to servers in rotation. Server A, then B, then C, then back to A.

It works well when all servers are equally powerful and requests cost roughly the same.

Least connections routes each new request to the server with the fewest active connections. This is smarter when request durations vary widely.

A server stuck on slow requests will not keep receiving new ones.

If servers have different capacity, assign weights. A server with weight 3 receives roughly three times as many requests as a server with weight 1.

• Weighted round robin
• Weighted least connections

IP hash routes a given client consistently to the same server based on a hash of its IP. This creates sticky sessions, useful when a server holds in-memory session state.

Note: stickiness undermines stateless design. Prefer external session stores when possible.

A load balancer periodically pings each backend with a health check (e.g. GET /health). Unhealthy servers are removed from rotation automatically.

This is how the system survives a server crash without manual intervention.

Layer 4 balancing operates on TCP/UDP, routing by IP and port — fast but blind to content. Layer 7 operates on HTTP, so it can route by URL path, headers, or cookies.

• L4: high throughput, simple
• L7: content-aware, supports path-based routing

At the largest scale, a single load balancer becomes a bottleneck. DNS-based balancing returns different server IPs to different clients, spreading load before traffic even reaches a balancer.

Often combined with regional balancers for global apps.

The load balancer itself must not be a single point of failure. Run it in an active-passive or active-active pair, with a floating virtual IP that fails over if the primary dies.

A typical scalable setup: DNS spreads clients across regions, regional L7 balancers do health-checked path routing, and least-connections distributes to a fleet of stateless app servers behind them.

Each layer removes a bottleneck and adds resilience.

You learned how load balancing makes horizontal scaling practical:

• Round robin, least connections, weighted, and IP hash algorithms
• Health checks remove failed servers automatically
• Layer 4 vs Layer 7, plus DNS balancing at scale
• The balancer must itself be redundant