Head-based vs tail-based trace sampling

What's really being asked

Whether you understand that sampling is a cost-versus-signal trade-off, and that where the decision happens changes what you can sample on.

The full answer

Head-based sampling makes the keep-or-drop decision when the trace begins, typically a probabilistic rate like one percent, and propagates that decision in the trace context so every downstream service agrees. It is stateless, cheap, and predictable, but because the decision precedes knowing the outcome, it drops most errors and slow requests proportionally, which is exactly what you most want to keep. Tail-based sampling defers the decision until the whole trace completes. A collector buffers all spans for a trace, then applies policies: always keep traces with errors, keep traces over a latency threshold, downsample the boring successful ones. This captures rare and pathological traces but requires holding spans in memory, routing all spans of a trace to the same collector instance, and tolerating added latency and infrastructure.

The mistakes people make

Claiming tail-based is strictly superior, ignoring its buffering and collector-affinity requirements, or thinking head-based can sample on error status (it cannot, the outcome is unknown yet).

What usually comes next

How do you ensure all spans of a trace reach the same tail collector? How do head and tail combine? What memory bounds matter?

A concrete example

At 100k requests per second, one percent head sampling keeps 1k traces but loses 99 percent of a rare 0.1 percent error class. A tail policy that always keeps error traces and samples successes at one percent retains every failing trace for debugging while still cutting volume dramatically, at the cost of running a buffering collector tier.