Learning Cactus

What Is a Control Plane and Why Load Balancers Don’t Discover Servers

January 9, 2026

When people first learn about load balancers, a very natural question comes up:

If new servers keep coming and going, how does the load balancer know where to send traffic?

The intuitive (but incorrect) assumption is that the load balancer actively discovers servers.

It does not.

Understanding why leads us to one of the most important ideas in system design: the control plane.

Two Different Worlds: Data Plane vs Control Plane

There are two different worlds defined which act behind the scenes for the control and the flow of data.

1. The Data Plane (Fast, Dumb, Predictable) This world is where:

  • The user data flows.
  • Packets are forwarded.
  • Decisions need to be fast.
  • Latency must be minimal. Load balancer lives in this world.

It's only job is to receive request, choose a healthy target(server) and forward request to this server.

2. The Control Plane (Slow, Smart, Authoritative)

This world is where:

  • Servers or instances are created or destroyed.
  • Health of the servers are evaluated.

This world decides:

  • Which and how many servers exist.
  • Which ones are healthy.
  • Which ones should receive traffic.
The control plane handles the system state and not the user traffic.

Why Load Balancers don't discover servers

The primary function of introducing load balancers in system design it to improve system performance, minimizing latency and containing failures.

It does not want to understand the configuration or working of a server or take up extra tasks like:

  • Scanning the network
  • Detecting new servers
  • Probing every IP
  • Deciding which servers are valid

This would immediately result into problems like:

  • Slowness - Discovery is expensive. Traffic routing must not be slow.

  • Unreliability - Network scans can be wrong, timeouts could happen and there could be cases of partial failures.

  • Mixed responsibilities - Traffic routing and system orchestration are very different concerns. These issues totally deviates the concept of introducing a load balancer into the system architecture.

So, systems are designed with a strict rule:

Load balancers are passive.

Discovery is orchestrated elsewhere.

So, Who Tells the Load Balancer About Servers?

The control plane.

Whenever something changes in the system, the control plane reacts.

Examples:

  • A new server is created
  • A server fails health checks
  • A server is terminated

Scaling rules are triggered

The control plane then:

  • Updates the list of valid backends
  • Updates the authoritative backend registry (often called a service registry or target list ), which load balancers use to update their local routing tables.

Remember, the load balancer never asks questions, it only follows instructions.

What the Control Plane Actually Does

Conceptually, the control plane:

  • Decides which instances belong to a service.
  • Evaluates health, readiness, and policy.
  • Maintains and registers the authoritative set of eligible backends.

This set lives in:

  • A registry
  • A control data store
  • A configuration source

Where Does the Control Plane “Register” Servers?

Conceptually, the control plane maintains an authoritative registry.

You can think of it as:

The single source of truth for which servers are allowed to receive traffic.

This registry may be:

  • A table
  • A data structure
  • A config store
  • An internal service The exact implementation varies, but the idea does not.

The control plane:

  • Knows all servers for all respective services.
  • Knows their state.
  • Decides their eligibility.
  • Reconciles differences between the current and desired state of instances for different services.

Control Plane: A Mental Model

One Control Plane:

  • Manages the entire system
  • Knows about all services
  • Enforces global rules
Per-Service State (Logical Isolation)

Inside that control plane, there are separate records for each service:

Control Plane
├── user-service
│   ├── instances
│   ├── health policy
│   └── scaling rules
│
├── payment-service
|   ├── instances
|   ├── health policy
|   └── scaling rules

So:

  • One control plane.
  • Many logical services.
  • Each with independent configuration.

Summary

In this post, I explored why load balancers don’t discover backend servers on their own and why a separate control plane exists.

I initially assumed load balancers were responsible for understanding system state, but they are intentionally passive. They don’t decide when to scale or which servers should exist. They simply route traffic to a list of backends they are given and stop sending traffic when those backends become unhealthy.

The control plane owns the system’s desired state. It decides when instances are created or removed and registers which ones are valid backends for a service. Load balancers then operate purely on this declared state.

Understanding this separation made it much clearer to me how scalable systems remain predictable and manageable.

What’s Next

  • How Auto Scaling Fits into the Bigger Picture
  • How Ingress Controllers Route Traffic to Different Services — and How They Differ from Load Balancers

Each post builds on the previous one, starting from fundamentals and gradually moving toward more complex system design concepts.

More posts in this series coming soon.