Load Balancing
System Design: lesson 3 of 15
One front door, many rooms behind it.
Lesson 3 of 15 · 5 min
Load Balancing
Step 1 of 12
The client resolves one public address. Three servers sit behind it, and it never learns their names.
The Idea
A load balancer accepts every incoming request and picks a healthy server to answer it. Round-robin cycles through the pool, least-connections favours whoever is least busy, and a hash on some key always sends the same client to the same server. Health checks quietly remove servers that stop responding.
Real-World Example
A blood donation clinic with six chairs and one greeter. Sending donors chair by chair looks fair until you notice a plasma donation occupies a chair three times as long. The greeter watches which chairs are genuinely free — the same reason least-connections beats round-robin on uneven work.
The Tradeoff
The balancer is now the thing everything depends on, so it needs its own redundancy. Sticky routing keeps a user's state on one server but unbalances the pool and turns a single crash into logged-out customers, which is why that state usually moves into a shared store instead.
Your turn
Put the steps in the right order.
- The balancer picks a healthy server using its routing policy
- The client resolves one public address and connects to it
- The response travels back through the balancer to the client
- The request is forwarded, and that server's health keeps being probed
Mini quiz
1 / 3