Transport Layer
Uses IP addresses, ports, and transport protocols. It sees less of the request, allowing simple and fast routing decisions.
Lesson 3 · Horizontal scaling
One service address. Three interchangeable replicas.
The client sends GET /api/products to
localhost:7312. Nginx understands the HTTP path and
distributes requests across healthy Catalog Service instances.
Interactive architecture lab
Distribute traffic, then remove a replica.
Run six requests to reveal round robin, stop one instance, and verify that the healthy replicas keep answering.
Known destination
http://localhost:7312/api/products
You can run the same request in Postman.
Start the lesson, then execute a request through the Load Balancer.
Execute a request to inspect the original response.
Execute a request to inspect the response headers.
One stable address
L7
Client-facing address
round robin
localhost:7312
Upstream group
catalog_pool
Published address
localhost:7312The only address known by the client.
Container listener
loadBalancer1:80Nginx accepts requests here inside Docker.
Selection strategy
Round robinNginx uses this strategy by default.
Application rule
HTTP path /api/productsThis is why the balancer is operating at Layer 7.
upstream catalog_pool {
server catalogService1:6212;
server catalogService2:6212;
server catalogService3:6212;
}
Load Balancer log · request → selected server
Start the lesson to see distributed requests.
Healthy upstream pool
Catalog Service replicas
Observe the distribution
Which replica handled each request?
Every request reaches exactly one healthy Catalog instance. Nothing is served from cache in this lesson.
Latest selection
WAITING
Execute a request to begin.
Total requests0
Healthy replicas0 / 3
Routing history
No requests yet
-
1
Start the lessonThe trace will reveal how the Load Balancer selects a replica.
Availability experiment
1
Run six requests and observe an even distribution.
2
Kill any replica from its compact card.
3
Send more requests; healthy replicas continue answering.
4
Restore the pool and return to three instances.
What this teaches
Distribute traffic across multiple servers.
A load balancer sits in front of multiple application servers and distributes incoming traffic between them.
Application Layer
Understands HTTP methods, paths, headers, hostnames, and cookies. It can make content-aware routing decisions with additional processing.
A Load balancer behaves much like a specialized reverse proxy. In
this lesson, Nginx can see the /api/products path
before selecting a Catalog replica.
- Round robinRequests are assigned to healthy servers in a repeating sequence, giving each one a turn.
- Horizontal scalingCapacity is increased by adding more server instances rather than making one server larger.
- Health checkA periodic test determines whether a server is available to receive traffic.
- FailoverTraffic is sent to another healthy server when the preferred server cannot answer.
What this gives us
- Traffic distributed across replicas
- Horizontal scaling
- Better resource utilization
- Service availability when one replica fails
- One stable address for the Catalog Service
- Selection of a healthy application instance
What still remains
- The Load Balancer is now a Single Point of Failure (SPOF)
- It handles only the Catalog Service
- The client still needs different addresses for User, Order, and other services
- Authentication and rate limiting remain distributed concerns