30% offEnding soon
FSD-028Frontend system design Premium

Design a Network Waterfall Panel

Design a trustworthy network waterfall with incremental events, timing phases, zoom, virtualization, retention, and safe export.

Advanced 55 min read

A network waterfall is not a collection of colored rectangles. It is a synchronized view of request evidence. Each table row, phase bar, details panel, filter result, and exported entry must refer to the same request occurrence and the same monotonic capture clock.

A useful panel starts recording before a request begins, grows the row as new evidence arrives, and remains understandable after failures, redirects, cache hits, service-worker responses, reloads, or long streams. The visual design matters, but the hard part is preserving truth while the evidence is incomplete.

The browser surface should own projection state such as selection, filters, grouping, sort, zoom, pan, and the mounted row window. A privileged host, browser extension, or debugger service should own network event access, request IDs, timestamps, redaction, body-retention policy, and durable captures.

Clarify the capture contract

Ask where events come from. A browser-integrated tool can see request and response headers, initiators, redirects, protocol details, and precise lifecycle events. A normal webpage usually has only the narrower Resource Timing view and cannot promise DevTools-level visibility.

Also ask whether recording survives reloads, whether bodies are retained, how large a capture can become, which timing source is monotonic, how cross-origin evidence is represented, whether HAR import and export are required, and which fields are sensitive.

For this design, assume an authenticated debugging product with a host bridge that emits stable request IDs and monotonic timestamps. Preserve log can keep completed rows across a navigation. Bodies are optional and budgeted. Desktop is the primary analysis surface; mobile supports capture summaries, filtering, row selection, and details.

Reimplementing the browser network stack, decrypting transport traffic, or inferring timing that the host did not expose is outside scope.

The public interview prompt

Design a network waterfall panel for a browser debugging product. Explain:

  • capture sessions, navigation boundaries, Preserve log, and stable request identity;
  • incremental events, duplicate delivery, out-of-order evidence, streaming, failure, redirect, retry, cache, and service-worker cases;
  • timing normalization, unavailable phases, monotonic clocks, Server Timing, and one shared ruler;
  • synchronized table and bars, zoom, pan, clipping, selection, filters, grouping, and details;
  • row virtualization, rendering choices, memory budgets, body retention, and long captures;
  • HAR import and export, credential redaction, authorization, and privacy;
  • keyboard and screen-reader behavior, loading and partial states, observability, tests, and rollout.

What the premium solution covers

The complete solution starts from raw lifecycle evidence and derives a trustworthy visual model. It defines capture generations, idempotent event merge, request and redirect identity, partial timing, zoom geometry, synchronized virtualization, details retention, initiator relationships, safe HAR workflows, accessibility, performance budgets, observability, and a staged rollout.

Original media follows one request from queued to complete across a preserved navigation, separates timestamps from derived phases, explains capture and viewport coordinates, and turns memory retention into an explicit ledger. Two deterministic labs let the reader merge lifecycle events and test clipping under a row 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 network waterfall?
Store one normalized request record per host-issued request ID. Keep raw lifecycle evidence and timestamps in that record, then derive the table cells, timing phases, bar geometry, details, and export from the same identity.
Why should a waterfall not use the URL as request identity?
The same URL can be requested many times through retries, polling, redirects, cache revalidation, and repeated fetch calls. Each occurrence needs its own request ID so late events cannot update the wrong row.
How should a waterfall handle missing timing phases?
Show the timing that is available and label unavailable or privacy-masked phases. Do not turn missing DNS, TLS, or server timing into zero-duration work because that invents evidence.
How do zoom and pan work in a network waterfall?
Keep a fixed capture time domain, derive a visible time window from zoom and pan, then project each request interval into pixels. Clip bars at the viewport edges without changing their stored timestamps or request identity.
How can a waterfall display thousands of requests?
Virtualize table rows and timing bars from one shared row projection, use bounded overscan, keep details outside the row, and retain only budgeted headers, samples, and bodies.
Is HAR export safe by default?
No. Exports can contain credentials, cookies, tokens, query parameters, request bodies, and personal data. Apply server-owned authorization and redaction, require an explicit sensitive-data choice, and record the export policy.