30% offEnding soon
FSD-027Frontend system design Premium

Design a Distributed Trace Viewer

Design a trace viewer for partial span trees, large waterfalls, filtering, correlation, accessibility, and late telemetry.

Advanced 58 min read

A trustworthy trace viewer does not draw whatever spans happened to arrive and call it a tree. It keeps one stable identity for each span across topology, timing, details, filters, and correlated evidence. Missing parents, sampling gaps, clock uncertainty, and late telemetry stay visible as evidence quality, not hidden as rendering cleanup.

A distributed trace can contain a handful of spans or tens of thousands. It can arrive as a complete lookup, a partial snapshot, or a snapshot followed by late patches. The same trace must work as a nested outline, a time waterfall, a searchable evidence set, and a launch point into logs and metrics.

The browser should own the current trace revision, normalized span entities, expansion, filtering, selection, virtualized projection, timing viewport, and inspector state. The service should own authorization, trace lookup and search, normalization, redaction, sampling metadata, durable retention, and permission-checked correlation links.

Clarify the investigation contract

Ask whether the product starts from a trace ID or a search result, whether traces can receive late spans, how partial traces are marked, whether clock-quality metadata exists, how many spans a trace may contain, which attributes are sensitive, and whether critical-path analysis is guaranteed or only estimated.

For this design, assume an authenticated observability product. A trace lookup returns a revisioned snapshot and may later return patches. Span and trace IDs are stable. Desktop is the primary analysis surface. Mobile supports search, outline navigation, selection, and details, but not every dense comparison mode.

Building the collector, implementing a query language, repairing service clocks, or inventing missing telemetry is outside scope.

The public interview prompt

Design a distributed trace viewer that supports small and very large traces. Explain:

  • trace lookup, search, revisions, partial results, sampling, and late spans;
  • normalized span identity, parent-child topology, orphan and cycle handling;
  • hierarchy depth, start time, duration, overlap, clock skew, and critical-path uncertainty;
  • expansion, selection, contextual filtering, waterfall zoom, and synchronized scrolling;
  • row and bar virtualization, worker boundaries, attribute budgets, and mobile fallback;
  • events, links, logs, metrics, errors, and permission-checked correlation;
  • loading, missing, stale, partial, malformed, and unsupported states;
  • keyboard behavior, screen-reader alternatives, privacy, observability, testing, and rollout.

What the premium solution covers

The complete solution builds one trace from normalized evidence without erasing uncertainty. It defines revision guards, orphan handling, the two-coordinate waterfall model, safe late-span merge, contextual filtering, large-trace virtualization, critical-path limits, correlation contracts, accessibility, security, observability, tests, and an evolution path.

Original media shows a missing parent arriving without moving the selected span, separates hierarchy from elapsed time, contrasts long work with causal latency, and maps one span through outline, waterfall, and inspector. Two deterministic labs let the reader assemble an out-of-order trace and test context-preserving filters under a DOM budget.

Premium solution

Continue with the complete system design

Unlock the architecture, state machine, API contracts, original diagrams, positioning model, accessibility decisions, performance budgets, testing plan, rollout strategy, scoring rubric, and interview walkthrough.

  • Detailed, beginner-friendly explanation
  • Production failure modes and trade-offs
  • Mobile-friendly architecture diagrams
  • Senior and staff-level interview signals
Unlock Premium

Frequently asked questions

What is the core data model for a distributed trace viewer?
Normalize spans by stable span ID, keep parent-child adjacency separately, and derive the expanded tree and waterfall rows. Store trace revision, selection, filters, timing domain, and warnings outside row components.
How should a trace viewer handle missing parent spans?
Show the affected span under an explicit missing-parent group or placeholder. Do not promote it to a verified root. If the parent arrives later, rebuild only the derived topology while preserving selection and the scroll anchor by span ID.
Is the longest span always the critical path?
No. A long span can run in parallel and contribute little to end-to-end latency. Critical-path analysis needs causal or blocking semantics, overlap handling, and honest uncertainty when instrumentation does not prove the dependency.
How do you render a trace with thousands of spans?
Flatten only expanded branches, virtualize outline rows and waterfall bars from the same row projection, limit attribute rendering, and retain selection in a pinned inspector. Canvas can help with dense bars, but semantic controls still need a DOM representation.
How should filtering work in a hierarchical trace?
Keep matching spans plus dimmed ancestor context so a deep match does not appear to be a root. Make hidden descendants and partial results explicit, and keep filter state separate from expansion and selection.
How do logs and metrics correlate with a selected span?
Use server-issued, authorized correlation links built from stable IDs and a bounded time range. The client should not copy arbitrary attributes into provider URLs or assume that every user may read the linked data.