> Your load balancer can distribute traffic perfectly and still overload a server. Here's the part of Round Robin we often overlook.

Three servers. Six requests.

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A
Request 5 → Server B
Request 6 → Server C

Perfect.

Every server got exactly two requests.

So the load is balanced... right?

Not necessarily.

This is where a simple load-balancing diagram can hide a surprisingly important production problem:

Equal traffic does not mean equal work.

The Problem Isn't the Algorithm

Round Robin is beautifully simple.

You have three servers:

A → B → C → A → B → C

Each new request goes to the next server.

For many systems, that's perfectly reasonable.

The interesting part is what happens when the requests aren't equal.

Imagine this traffic:

GET  /health
POST /generate-report
GET  /profile
POST /export-large-file
GET  /products
POST /process-video

Round Robin might still produce:

Server A → 2 requests
Server B → 2 requests
Server C → 2 requests

On paper:

A = B = C

In production:

Server A  ███░░░░░░░  25%
Server B  █████░░░░░  48%
Server C  █████████░  91%

Same request count.

Very different workload.

One Request Is Not One Unit of Work

A health-check request might finish in a few milliseconds.

Generating a large report could involve:

• multiple database queries
• significant memory
• CPU-heavy processing
• external API calls
• several seconds of execution

To a basic Round Robin strategy, both are still:

1 request

And that's the trap.

We often think we're distributing load.

What we're actually distributing is requests.

Those are not always the same thing.

Servers Aren't Always Equal Either

There's another assumption hiding here.

Imagine:

Server A → 8 CPU / 16 GB
Server B → 8 CPU / 16 GB
Server C → 2 CPU / 4 GB

Sending roughly 33% of traffic to each server probably isn't what you want.

That's where Weighted Round Robin helps.

A → Weight 4
B → Weight 4
C → Weight 1

The stronger servers receive more traffic.

Better.

But there's still a problem.

Weights describe what a server is expected to handle.

They don't necessarily describe what it can handle right now.

Server A could currently be:

CPU:         94%
Memory:      87%
Connections: 143

while Server B is sitting comfortably at 30%.

A static rotation doesn't inherently understand that.

So We Need Smarter Algorithms?

Sometimes.

Least Connections, for example, considers how many active connections each server currently has.

Instead of asking:

Whose turn is next?

we're asking:

Who looks least busy right now?

That's often more useful when request duration varies significantly.

But even that isn't perfect.

10 lightweight requests

could consume fewer resources than:

2 expensive requests

Which reveals the real problem.

What Does "Load" Actually Mean?

This is the question I think matters more than:

"Which load-balancing algorithm should I use?"

Ask:

What does load mean for this particular system?

Maybe it's:

CPU usage
Memory pressure
Active connections
Request latency
Queue depth
Database pressure
Downstream dependency latency

Or a combination of them.

Because you can have perfectly balanced application servers while something downstream is burning:

Server A ─┐
Server B ─┼──────► Database 🔥
Server C ─┘

Your load balancer says everything is fine.

Your database strongly disagrees.

Round Robin Isn't Bad

This is important.

Round Robin is not a bad algorithm.

For stateless services with similar instances and reasonably predictable requests, its simplicity can be a major advantage.

Simple systems are easier to understand, operate and debug.

The mistake isn't using Round Robin.

The mistake is assuming:

Equal Requests = Equal Load

without checking whether that's actually true for your workload.

The Part Worth Remembering

Load balancing is really a scheduling decision:

Where should the next piece of work go?

Round Robin answers:

"Who's next?"

Weighted Round Robin asks:

"Who's next, considering capacity?"

Least Connections asks:

"Who's least busy?"

More adaptive approaches can ask:

"Who looks healthiest right now?"

There isn't one universally correct answer.

It depends on what you're trying to balance.

So next time your architecture diagram looks like this:

              Load Balancer
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
          A         B         C
         33%       33%       33%

don't just ask:

"Is traffic evenly distributed?"

Ask:

"What exactly did we balance?"

That's usually where the more interesting system-design conversation begins.