Load Balancing Explained — L4 vs L7, Algorithms, Health Checks
Distribute traffic across healthy backends using L4/L7 algorithms and health checks.
A load balancer is a traffic cop for your servers. Without one, all requests hit a single server until it breaks. With one, traffic is spread across a pool of servers — so you can handle 10× the load by adding 10× the servers, and no single server failure takes down the entire application.
L4 load balancers operate at the TCP/IP layer — they route traffic based on IP addresses and port numbers without looking at the content. They're fast (millions of connections per second) but dumb. L7 load balancers operate at the HTTP layer — they can route based on URL paths, headers, cookies, and body content. They're more powerful but slower because they need to decrypt and inspect each request.
The choice of algorithm determines which server each request goes to. Round-robin works well for stateless, homogeneous requests. Least-connections works better when requests take variable time (some are fast, some take seconds). Consistent hashing (used for caches and sharded databases) ensures the same key always routes to the same server, preserving cache locality.
Key concepts
Step-by-step approach
- 1
Choose L4 or L7: L4 for non-HTTP protocols or maximum throughput; L7 for path-based routing, TLS termination, and header manipulation.
- 2
Select a routing algorithm: round-robin for fast homogeneous stateless requests; least-connections for variable-duration requests; consistent-hash for cache key locality.
- 3
Configure active health checks: protocol (HTTP GET /health or TCP connect), interval (5-30s), consecutive failure threshold (2-3 before removal), and recovery threshold.
- 4
Decide on sticky sessions: session affinity sends the same client to the same server (useful for stateful apps) but reduces the effectiveness of load balancing and complicates failover.
- 5
Plan for draining: before removing a server from the pool (deploy, maintenance), stop sending new connections but allow existing ones to complete — avoids dropped requests.
Key trade-offs
Round-robin vs. least connections
Round-robin works when all requests are similar in cost. If some requests take 100ms and others take 10 seconds, round-robin overloads servers with the long-running ones. Least-connections tracks actual server load and routes accordingly.
Active vs. passive health checks
Active checks (probe the backend at intervals) detect failures within seconds but add overhead. Passive checks (detect failures from failed real requests) have zero overhead but need real traffic to find failures.
DNS round-robin vs. L7 load balancer
DNS round-robin is simple and has no single point of failure, but it has no health checking, no session affinity, and TTL-limited failover speed. A real load balancer solves all of these.
Common pitfalls
No health checks: a load balancer without health checks will route requests to dead servers, causing failures for a percentage of users until the server is manually removed.
Session affinity without replicated sessions: if you use sticky sessions to route users to one server, what happens when that server dies? Users lose their session. Replicate session state externally (Redis) to avoid this.
Ignoring the load balancer as a single point of failure: a single load balancer is itself a SPOF. Use an active-passive or active-active pair of load balancers with a floating VIP.
Interview questions on this topic
Practice answering these with AI feedback → Start on CrackLab
Continue learning — explore 207 more topics on CrackLab DesignHub
From Classic HLD designs (Twitter, YouTube, Uber) to LLD patterns, distributed systems, databases, and company case studies.
Related topics
Move static and cacheable content close to users to reduce latency and origin load.
Proxies mediate traffic. Gateways add routing, auth, throttling, protocol translation, and observability.
Estimate users, QPS, storage, bandwidth, memory, fanout, and cost before choosing architecture.