The live part: a rolling window and every screen state
The events arrive as 1, 2, 4, 3, 4, 9, 5, 6, 7, 8: out of order, with a duplicate, and with a gap. The window ends up sorted, de-duplicated and 5 long.
A frontend system-design round asks you to plan a whole product screen, not write one function. You practise the order of a good answer on a live metrics dashboard: requirements, data flow, rendering choice, real-time updates, states, accessibility and a performance budget with numbers.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Draw the data flow for a page showing stations on a map, with a filter and a table twin. Name the one place that owns the filter state.
For a dashboard with 5,000 viewers instead of 50, and data that changes every second, what changes in your answer to "how does data arrive"? Give two changes.
Write the screen-state function for a chart that has partial failure: the rides line loaded, the station map failed. What does each chart show?
Explain it without notes
How do you start a frontend system-design answer for a metrics dashboard?
When would you choose polling, SSE or WebSockets for the live data?
Which states does a dashboard chart need, and why?
How do you set and check a performance budget?
Console
(nothing was printed)Expected console output
window: 5,6,7,8,9
a point older than the window is dropped: 5,6,7,8,9
loading no data -> loading: show a skeleton
error no data -> error: message and a retry button
ok 0 rows -> empty: say what is missing and why
ok 3 rows -> ok: draw 3 points
ok 3 rows -> stale: badge 'data is 95 s old'
error 3 rows -> stale: keep the old chart, badge 'offline, last update 95 s ago'