Load Balancers

Before diving in, let's understand each component you'll see on the canvas:

💻 Client

The Client is the starting point of every request — think of it as a browser, mobile app, or any user device. It sends HTTP requests (GET, POST, etc.) to the network. In this simulation, the client sends 3 identical GET requests back to back.

⚖️ Load Balancer

The Load Balancer sits between the client and your servers. It intercepts every incoming request and decides *which server* should handle it. The client never talks directly to a server — it always goes through the load balancer first.

🖥️ Web Servers (×3)

The three Web Servers are identical backend workers. Each one can independently handle the same requests. The load balancer decides which of them gets each incoming request.

In this diagram: Client → Load Balancer → Server 1 / Server 2 / Server 3

A Load Balancer acts like a traffic manager at a busy intersection. Instead of letting all cars pile onto one road, it spreads them across multiple roads.

Why Do We Need It?

Imagine 1,000 users hitting your app at the same time. If they all reach a single server:

- That server gets overloaded → slowdowns and crashes

- If that server goes down → your entire app goes down

With a load balancer:

- [High Availability](/learn/glossary/high-availability): If Server 1 crashes, traffic automatically reroutes to Server 2 and 3 — users don't notice.

- Horizontal Scaling: Need more capacity? Add another server behind the load balancer without changing anything on the client side.

- Resource Optimization: No single server gets overwhelmed — CPU and memory are spread evenly.

Watch It in Action

Press Play on the simulator to the right. You'll see the client send 3 requests. Watch the animated purple dots (packets) — they should travel to different servers each time.

Load balancers use different algorithms to decide where each request goes:

Round Robin *(default in this sim)*

Routes requests sequentially: Request 1 → Server 1, Request 2 → Server 2, Request 3 → Server 3, then back to Server 1. See details under Load Balancer.

Best for: Servers with roughly equal capacity.

IP Hash

Hashes the client's IP address (e.g., 192.168.1.50) to a specific server. The *same client always hits the same server* — useful when you need session persistence (e.g., shopping carts, login state).

Least Connections

Routes each new request to whichever server currently has the *fewest active connections* — great when some requests take much longer than others.

Interactive Checkpoints

Click the buttons below to instantly apply different strategies and re-run the simulation:

In the real world, servers crash or go under maintenance. The load balancer constantly runs health checks — pinging each server to confirm it's alive. If a server's capacity drops to 0 (or it stops responding), the load balancer skips it.

Try It Yourself

This is automatic failover in action. No client-side change is needed.

🛠️ Go Practice in the Sandbox!

Now that you understand Load Balancers, try building your own from scratch: