Most OpenTelemetry deployments start with a very simple architecture:

Applications → OpenTelemetry Collector → Observability Backend

For small workloads, this work well.

But what happens when telemetry volume grows, multiple teams start sending data, tail sampling is introduced, or the backend becomes temporarily unavailable?

At that point, scaling the Collector is no longer just a matter of increasing the replica count.

In this session, we will build an OpenTelemetry Collector pipeline from the simplest possible deployment and progressively push it until the architecture starts to fail.

We will begin with a single Collector receiving traces from instrumented applications and synthetic telemetry generators. As load increases, we will observe the Collector itself using its internal telemetry and identify signs of saturation such as CPU pressure, growing exporter queues, failed exports, and refused telemetry.

We will then horizontally scale the Collector and explore the next challenge: stateful processing.

Using tail sampling as an example, we will demonstrate why simply load balancing spans across multiple Collector replicas can produce incorrect or incomplete sampling decisions when different spans from the same trace arrive at different instances.

From there, we will evolve the architecture into a multi-tier Collector topology using trace-aware routing, dedicated processing Collectors, and scalable gateway patterns.

Finally, we will simulate backend failure and observe how queues, retry behaviour, and pipeline recovery affect telemetry reliability.

This is a live engineering session focused on understanding how OpenTelemetry Collector architectures change as telemetry volume, processing complexity, and reliability requirements grow.

The goal is not to present a single “correct” architecture, but to understand the engineering trade-offs that determine when one Collector is enough — and when it is not.