Some paths require a wider view. Return on a larger screen.
Threads Between
Some connections are not parent and child.
They are peers, linked across separate journeys.
An order-processor service consumes messages from a queue. Each message was produced by a different user's checkout trace. The processor creates its own span — but needs to reference back to each original trace.
three separate traces produce messages
Trace A
checkout-1
→
queue
Trace B
checkout-2
→
queue
Trace C
checkout-3
→
queue
Trace D (its own trace)
order-processor
Trace Alink
Trace Blink
Trace Clink
The order-processor lives in its own trace. But it holds links — dotted threads back to each producer span. Neither trace is broken. Both remain whole.
child-of vs. span link
child-of
A span can only have one parent. Making the consumer a child of a producer trace would steal it into the wrong trace and break the consumer's lineage.
span link
A link says "this span is related to that span" without parent-child ownership. Both traces stay intact. One span can hold many links.
The order processor handles messages from three different traces. How should it connect to them?
How are span links different from parent-child relationships?
Not all connections are hierarchical.
Span links let you say "this work was related to that work" without breaking either trace's lineage.