How do you build a performant visualization for millions of time-series points?

WHAT THIS TESTS: This question evaluates whether you can architect a complete data pipeline for rendering massive time-series datasets without crashing the browser. The interviewer cares about your understanding of visual fidelity versus statistical precision, computational complexity, and the separation of concerns between backend reduction and frontend rendering. They want to see that you treat the browser as a thin client that receives only what it can paint, not a dump for raw telemetry.

A GOOD ANSWER COVERS: First, backend downsampling using a shape-preserving algorithm such as Largest Triangle Three Buckets. Explain that LTTB runs in O of n time with O of 1 extra space, buckets the data, and selects points that maximize triangle area with neighboring buckets so peaks and valleys survive. Second, multi-resolution storage or on-the-fly tiered aggregation so the backend can serve different resolutions based on zoom level rather than sending the full series. Third, viewport-aware data fetching: only request the time range and granularity currently visible, using min-max aggregation for the highest zoom and LTTB for mid-level overviews. Fourth, frontend rendering optimization: use HTML5 Canvas or WebGL instead of SVG for millions of points, implement level-of-detail switching when the user zooms, offload data parsing to Web Workers, and use decimated hit-testing or separate high-resolution hover queries instead of keeping every point in the DOM.

COMMON WRONG ANSWERS: Suggesting simple every-Nth point sampling, which drops critical anomalies and produces jagged lines that mislead users. Proposing pagination of raw points, which breaks the visual continuity of a time-series line chart. Recommending server-side rendering of images, which eliminates interactivity like zooming and hovering. Ignoring the backend entirely and suggesting the frontend just virtualize a giant array, which still forces the network to transfer millions of points and saturates memory.

LIKELY FOLLOW-UPS: How would you handle real-time streaming where new points arrive continuously? What happens when a user zooms from a ten-year view down to a single millisecond? How do you maintain deterministic results so cached tiles remain consistent? When would you avoid LTTB in favor of min-max or average aggregation? How do you balance pre-computed tiers versus on-demand downsampling for storage cost?

ONE CONCRETE EXAMPLE: A stock price dashboard holds ten million daily ticks. The backend stores pre-computed LTTB tiers at one thousand, ten thousand, and one hundred thousand point resolutions. When the user loads a one-year view, the API returns the one-thousand-point LTTB downsample in roughly ten to fifty milliseconds. As they zoom into a single week, the frontend requests the ten-thousand-point tier for that date range only. The chart renders via Canvas with a separate lightweight hover endpoint that returns the exact raw point nearest the cursor, giving pixel-perfect interaction without shipping the full dataset.