In this problem, I treat distributed tracing as a way to reconstruct how a single request flows through multiple microservices using span data. Each span contains a spanId, parentSpanId, and timing information, which I use to rebuild the execution structure. First, I build a map of all spans for quick lookup and then link each span to its parent to form a tree, where root spans represent entry points like an API gateway. This gives a clear view of how the request moves across services.
Once the trace is reconstructed, I focus on performance analysis. I identify slow spans by filtering those whose duration exceeds a threshold, which helps highlight individual service-level bottlenecks. More importantly, I compute the critical path, which is the longest dependent chain from root to leaf. This represents the true end-to-end latency experienced by the user and is more meaningful than isolated slow spans. I typically compute this by traversing the tree and selecting the child path with the maximum cumulative duration.
Along with performance, I also evaluate trace reliability. In distributed systems, traces can be incomplete, so I check for missing parent spans and broken relationships to detect gaps in observability. This helps identify instrumentation issues or data loss in the pipeline.
Overall, the solution runs in linear time since it uses a single pass to build the map and another traversal for analysis. In real-world systems, I would extend this to handle out-of-order spans, clock skew, and high-volume streaming data using buffering or tools like Kafka. For visualization, this data would typically be shown as a trace tree or flame graph, where slow spans and the critical path are highlighted to help engineers quickly debug and resolve performance issues.