Traefik 3.8's tap middleware triples request latency even with an instant local receiver

7.4 relevance

Detailed latency measurement of a new middleware, directly actionable for anyone using Traefik in production.

General dev.to

Answer the board on AI readiness

Arrive with evidence, not opinion. See how your foundation benchmarks against your peers, get a clear read, and leave with a ranked place to start.

Why It Matters

For platform engineers evaluating Traefik for production audit trails, this reveals the tap middleware's latency cost is strictly additive and doubles per request, making it unsuitable for latency-sensitive paths without careful receiver design and monitoring.

Key Takeaways

Benchmark tap middleware with your actual receiver latency before enabling it on production routers, and always set up log-based alerts for 'Unable to send the request record' since no metrics exist.

Traefik 3.8's tap middleware triples request latency even with an instant local receiver

Summary

Traefik 3.8.0-rc.1's tap middleware, designed for audit logging by copying requests/responses to a service, triples baseline latency even with an instant local receiver (2.6ms vs 0.88ms). Each request incurs two synchronous calls (request and response), so a 50ms receiver delay adds ~100ms, not 50ms. With rejectOnRecordError: true, an unreachable tap service causes 500 errors for all requests; with rejectOnRecordError: false, failures only appear in logs without built-in metrics, requiring custom alerting on middlewareType=Tap log lines.

Author

Alex Georgiev