Load Balancing Strategies
Learn how load balancers distribute traffic across multiple servers to enable horizontal scaling, and explore common routing algorithms and health checks.
Load Balancing Strategies is a free System Design Basics for Backend Developers lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the System Design Basics for Backend Developers learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why 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
Where the Balancer Sits
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.
Client --> [Load Balancer] --> Server A
--> Server B
--> Server CRound Robin
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.
requests = ['r1','r2','r3','r4']
servers = ['A','B','C']
for i, r in enumerate(requests):
print(r, '->', servers[i % len(servers)])Least Connections
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.
Weighted Algorithms
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 & Sticky Sessions
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.
def pick(ip, n):
return hash(ip) % n
print('192.168.0.5 ->', pick('192.168.0.5', 3))Health Checks
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 vs Layer 7
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
DNS Load Balancing
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.
Avoiding the Single Point of Failure
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.
Putting It Together
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.
Quick Check
Test your understanding of load balancing algorithms.
Recap
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
Frequently asked questions
Is the “Load Balancing Strategies” lesson free?
Yes — the full text of “Load Balancing Strategies” is free to read here on the web, and the System Design Basics for Backend Developers course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the System Design Basics for Backend Developers course, upgrade to CoddyKit PRO.
What will I learn in “Load Balancing Strategies”?
Learn how load balancers distribute traffic across multiple servers to enable horizontal scaling, and explore common routing algorithms and health checks. You practise System Design Basics for Backend Developers with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start System Design Basics for Backend Developers?
No prior experience is required. System Design Basics for Backend Developers on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Load Balancing Strategies” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this System Design Basics for Backend Developers lesson?
Yes. Every System Design Basics for Backend Developers lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Vertical vs. Horizontal Scaling
- Stateless vs. Stateful Services
- Introduction to Distributed Systems
- Load Balancing Strategies