Learn Traefik - Services & Load Balancing

#Introduction

After the router decides where a request goes, the service determines its final destination. Episode 7 dissects all of Traefik's service and load balancing mechanisms: the various service types, how to define multiple servers, load distribution, health checks, sticky sessions, and mirroring for testing.

Load balancing is the reason Traefik is often chosen as the gateway for microservices. Its ability to manage several backend instances transparently — plus health checks that maintain quality — makes horizontal scaling easy. Let us master it from the most basic side.

#Service Types

#Five Service Families

• HTTP service: serves HTTP/HTTPS requests, the most commonly used type.
• TCP service: forwards raw TCP connections — useful for databases, SSH, and non-HTTP protocols.
• UDP service: forwards UDP datagrams, for example for DNS or game servers.
• Weighted service: combines several services with percentage-based distribution — the basis for canary and blue-green deployments.
• Mirroring service: copies traffic to another service for shadowing without disturbing production.

Episode 7 focuses on the HTTP service; TCP and UDP are covered specifically in episode 18, while weighted and mirroring we unpack at the end of this episode.

#Basic Load Balancer

#Server Lists and Round Robin

By default Traefik does round robin: each request is forwarded to the next server in turn. In Docker, the server list is created automatically from scaled containers. In the file provider, you define servers manually:

http:
  services:
    web-svc:
      loadBalancer:
        servers:
          - url: "http://10.0.0.11:80"
          - url: "http://10.0.0.12:80"
        passHostHeader: true

passHostHeader: true is the default that forwards the original Host header to the backend — important because many applications decide virtual hosts based on this header. A value of false for passHostHeader will make the backend see Traefik's host instead of the visitor's real host.

#Health Checks

#Maintaining Backend Quality

Without health checks, Traefik forwards requests to backends that may already be down, producing 502s. Health checks fix this: Traefik checks backends periodically and removes unhealthy ones from rotation:

http:
  services:
    api-svc:
      loadBalancer:
        servers:
          - url: "http://10.0.0.21:3000"
          - url: "http://10.0.0.22:3000"
        healthCheck:
          path: "/health"
          interval: "15s"
          timeout: "3s"
          healthyStatuses:
            - 200
          followRedirects: true

The settings above check /health every 15 seconds with a 3 second timeout. Backends that do not return 200 are temporarily removed from rotation. Traefik also manages connections passively: if a backend fails to respond to a real request, it is also marked unhealthy. Health checks are the first line of defense for your service quality.

#Load Balancing Algorithms

#Round Robin and Weighted

Traefik's default algorithm is round robin. To control traffic proportions, use a weighted service that combines services with weights:

http:
  services:
    app-canary:
      weighted:
        services:
          - name: app-stable
            weight: 9
          - name: app-v2
            weight: 1

The combination above sends 90 percent of traffic to app-stable and 10 percent to app-v2. This pattern is the basis of canary deployment: gradually increasing the app-v2 weight while monitoring error rates, until the new version finally receives all traffic and the old version is removed. Each service still uses its own internal round robin.

#Sticky Sessions

#Consistency Within a Session

Some applications store state in a session — if the second request lands on a different server, the session is lost. Sticky sessions solve this by writing a cookie that marks the destination server:

http:
  services:
    app-svc:
      loadBalancer:
        servers:
          - url: "http://10.0.0.31:80"
          - url: "http://10.0.0.32:80"
        sticky:
          cookie:
            name: "session-affinity"
            secure: true
            httpOnly: true

A cookie named session-affinity is written on the first response; subsequent requests from the same client are always directed to the same server. The secure: true attribute makes the cookie sent over HTTPS only, and httpOnly: true prevents JavaScript from reading the cookie — a combination recommended for production.

#Service Mirroring

#Traffic Shadowing

A mirroring service copies requests to an additional service without affecting the primary response. The real response still comes from the primary service; the copy is sent in parallel only for observation:

http:
  services:
    app-mirror:
      mirroring:
        service: app-prod
        maxBodySize: 1048576
        mirrors:
          - name: app-staging
            percent: 100

This pattern is very useful for testing a new version: send all production traffic to a staging version to observe, without changing anything users receive. Use percent to control how much of the request traffic is mirrored. This app-mirror service is what the router references, not the original service.

#Closing

Key takeaways:

• Service types: HTTP, TCP, UDP, weighted, and mirroring.
• The load balancer uses round robin by default; passHostHeader forwards the original host.
• Health checks ensure only healthy backends receive traffic.
• Weighted services are the basis of canary deployments.
• Sticky sessions use a cookie, but stateless design is still better.
• Mirroring copies traffic for shadowing without affecting users.

In episode 8 next we will cover middleware fundamentals — the request chain and response chain concepts, execution order, how to chain several middlewares, HTTP and TCP middleware types, and common patterns for authentication, security headers, and request modification. This opens the gate to the third phase of the series.