Skip to main content

Traffic Mirroring

Traffic mirroring duplicates incoming requests to one or more secondary services while only returning the response from the primary service. Responses from mirrors are discarded — users always see the primary's response. This lets you validate a new service version with real production traffic patterns, real payloads, and real edge cases without any risk to users.

Mirroring is often the first step before canary deployments or A/B testing — mirror to validate, then shift live traffic.

Configuration Example​

Configure a TraefikService with the mirroring spec. The percent field controls what fraction of traffic is copied to the mirror.

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: my-app
  namespace: apps
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`app.example.com`)
      kind: Rule
      services:
        - name: app-mirror
          namespace: apps
          kind: TraefikService
  tls: {}

In this example, 100% of traffic goes to app-v1 (and users always see its response), while 10% of that traffic is also copied to app-v2 for testing.

Resource consumption

Mirrored requests consume resources on the mirror target. Be mindful of the percent value, especially for high-traffic services. The mirror service receives the full request including headers and body.

Monitoring the Mirror​

Since responses from the mirror are discarded, failures won't appear in your client-facing metrics. You need to monitor the mirror service directly:

  • Logs — Watch for error responses, panics, or unexpected behavior in the mirror's application logs.
  • Traces — Compare the mirror's trace spans against the primary's. Look for latency spikes or missing spans that indicate the mirror is struggling with certain request patterns.
  • Error rates — Track the mirror's HTTP status codes independently. If the mirror returns 500s on 2% of requests, you know exactly what to fix before any real user sees that service.

This is where the observability foundation matters most. The gateway's OpenTelemetry data gives you the primary's baseline, and the mirror's own instrumentation tells you how it handles the same traffic. Compare the two.

Progressive Mirroring​

Start with a low percentage and ramp up as the mirror stabilizes:

Update the percent field in the TraefikService at each stage. Once the mirror handles 100% of traffic cleanly, you're ready to transition to live traffic splitting with a canary deployment or A/B test.

Multiple Mirrors​

You can mirror to more than one service simultaneously. Each mirror receives an independent copy of the request:

apiVersion: traefik.io/v1alpha1
kind: TraefikService
metadata:
  name: app-multi-mirror
  namespace: apps
spec:
  mirroring:
    name: app-stable
    port: 80
    mirrors:
      - name: app-v2
        port: 80
        percent: 100
      - name: app-v3
        port: 80
        percent: 50

This sends 100% of traffic copies to app-v2 and 50% to app-v3, while the primary app-stable handles all real responses.

Related Content​