How Ingress Controllers Route Traffic to Different Services and How They Differ from Load Balancers

January 20, 2026

In the previous posts, we focused on how systems scale a single service: how load balancers distribute traffic, how the control plane manages server membership, and how auto-scaling adjusts capacity over time. All of these concepts assume a simple model — one entry point serving replicas of the same service.

Real systems don’t stop there.

As soon as you introduce multiple services — user service, payment service, search service — a new problem appears: how does incoming traffic get routed to the right service in the first place? This is where ingress controllers come in, and why they exist as a separate layer rather than an extension of load balancers.

The Core Distinction

Before definitions, this is the most important idea:

A load balancer distributes traffic within a service.
An ingress controller routes traffic between services.

They solve different problems at different layers.

If we blur this distinction, the architecture quickly becomes hard to reason about.

The Single Service World

Up to now, the system looked like this:


  Client
    │
    ▼
Load Balancer
    │
    ▼
Service Instances

All instances run the same service
Load balancer only cares about health and availability
Routing decisions are trivial: “pick a healthy instance”

This model breaks down as soon as we add more services.

The Multi-Service Problem

Imagine a system with multiple services:

/users → user service
/payments → payment service
/orders → order service

Without an ingress layer, you are forced into one of two bad options:

Expose a separate public endpoint per service
Add routing logic into each service or load balancer Both scale poorly.

This approach increases operational complexity long before it causes performance issues.

This is not a performance problem - it is a control and complexity problem

What an Ingress Controller Actually Is

At a fundamental level:

An ingress controller is a traffic router that maps external requests to internal services based on rules.

Those rules might look like:

Path-based routing (/users, /payments)
Host-based routing (api.example.com, admin.example.com)
Header-based routing (advanced cases)

But the key point is this:

The ingress controller does not route to individual servers — it routes to services.

Ingress Introduces a Logical Service Layer

With ingress, the flow looks like:


Client
   │
   ▼
Edge Load Balancer → Handles internet-facing concerns
   │
   ▼
Ingress Controller → Routes requests to services
   │
   ▼
Logical Service → Distributes traffic to instances of a service
   │
   ▼
Service instance  → Execute business logic

Each layer solves a distinct problem. Together, they form a system that is both scalable and easy to reason about.

Here’s what’s new:

Logical service: an abstraction representing “all instances of a service”
Ingress routes requests to a logical service
The service abstraction handles instance-level distribution

The logical service performs instance-level distribution by spreading traffic across the instances of a service.

This is why ingress scales conceptually even as the system grows.

Summary

In systems that consist of a single service, load balancers are sufficient. They distribute traffic across identical instances and ensure availability.

As systems grow and introduce multiple services, a new problem emerges: deciding which service should receive a request. This problem is not about capacity, it is about routing, ownership, and control.

Ingress controllers solve this by introducing a dedicated routing layer. They examine incoming requests and map them to logical services, while leaving instance-level distribution to the service abstraction itself.

In short:

Load balancers distribute traffic within a service
Ingress controllers route traffic between services
Logical services abstract away instance-level complexity

Separating these responsibilities keeps systems scalable, flexible, and easier to reason about as they evolve.

What’s Next

This post focused on ingress controller. In upcoming posts, I plan to cover:

Why Ingress Sits Behind 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.