• It’s a distributed system component that makes it easy to scale the load horizontally.
  • It acts as the ONLY point of contact, between client and server.

(Users don’t need to know how many servers are behind the load balancer)

Usually, the load balancer has either a static IP or a static DNS name.

So, clients only know one `example.com` which is where they need to send requests.

:)

Free to read link

:)

Request–Response Flow

Steps:

  1. The client already knows the domain of the load balancer (say example.com)
  2. It makes an API call like GET example.com.
  3. The load balancer receives it and decides which server should handle this request (based on its chosen algorithm)
  4. Once the server responds, the load balancer passes that response back to the client.

Load Balancing Algorithms

1. Round Robin

For uniform infrastructure which means when all servers have roughly the same capacity and performance.

Requests/Load are distributed iteratively: once the last server gets a request, the next one loops back to the first.

Round Robin Algo

2. Weighted Round Robin (WRR)

For non-uniform infrastructure.

Here, each server gets requests based on its “weight.”
If Server 1 has 2 GB RAM and Server 2 has 4 GB RAM, then Server 2 should get roughly twice as many requests.

Example

Servers:
 A (weight = 3)
 B (weight = 2)
 C (weight = 1)

Requests are distributed in this ratio:
 A → A → A → B → B → C → A → A → A → B → B → C …

So A gets 50% of the requests, B gets 33%, and C gets 17%.

Use case: large or mixed infrastructure (e.g., one powerful server and two smaller ones).

3. Least Connections

This one picks the server that currently has the fewest active connections.

It’s perfect when variance is a lot (or request times vary a lot)

Like, one request might take 5 minutes, while another takes 5 seconds.

So instead of distributing blindly, it dynamically checks which server is “free enough”

Weighted Least Connections (WLC)

Same idea, but it factors in server capacity as well.

Now, let’s talk about those which FAANGs love the most, while taking interviews.

4. Hash-Based Routing

Naïve Hashing

You take a key (like user ID/Client ID etc) and assign it to a server using:
 server = hash(key) % N

If you have 3 servers (A, B, C), keys are mapped like this

server = hash(key) % 3

Pros: Simple and sticky (same key always goes to the same server).

Cons: If one server goes down, you have to reassign everything

(server = hash(key) % 2),

which is inefficient.

5. Consistent Hashing

Consistent hashing fixes that inefficiency which hash based routing has.

So, what it does is that It maps both servers and keys (which is the client id or so) onto a hash ring. And each key goes to the next server clockwise.

So, when a server is added or removed, only a small subset of keys are reassigned, giving it scalability and stability.

Example:

  • user a → b
  • user b → c
  • user c → a

If we remove server c, user b now goes to server a.

Not everyone needed to be reassigned :)

  • Static algorithms — The load balancer makes decisions using fixed rules (like round robin or hashing). It doesn’t check real-time server load.
  • Dynamic algorithms — These monitor real-time metrics (like CPU usage or connection count) and make smarter, load-aware decisions.
  • Sticky algorithms/sessions mean once a user is assigned to a server, all future requests from that same user go to that same server.
                        ┌────────────────────────┐
                        │      Load Balancer     │
                        └──────────┬─────────────┘
                                   │
               ┌───────────────────┼───────────────────┐
               │                   │                   │
        Static Algorithms     Dynamic Algorithms   Consistent / Sticky
               │                   │                   │
               ▼                   ▼                   ▼
        ┌──────────────┐     ┌──────────────┐     ┌───────────────────────┐
        │ Round Robin  │     │ Least Conn.  │     │ Consistent Hashing    │
        └──────┬───────┘     └──────┬───────┘     └──────────────┬────────┘
               │                    │                           │
               ▼                    ▼                           ▼
       ┌─────────────┐       ┌─────────────┐           ┌─────────────────────┐
       │ Weighted RR │       │ Weighted LC │           │ IP Hash / Cookie LB │
       └─────────────┘       └─────────────┘           └─────────────────────┘
This is part of my system design notes for junior engineers.

In case we are meeting for the first time, come over here, it’ll be worth the roller coaster of articles that are gonna come up in the next few weeks.

Have you read this -How a Single Line of Python Code Broke Production?