Design a Analytics dashboard

01Concrete scale assumptions

02Architecture decisions and rationale

03Client contracts and data boundaries

1type DashboardQuery = { metric: string; from: string; to: string;2  grain: 'minute' | 'hour' | 'day'; timezone: string;3  filters: Record<string, string[]>; dimensions: string[] };4type SeriesResponse = { generatedAt: string; partial: boolean;5  series: { key: string; points: [number, number | null][] }[] };

04Failure-mode analysis

05Observability and operations

• Measure query latency, queue time, cache hit rate, response bytes, partial-result rate, and widget error rate by metric.
• Track long tasks, chart render duration, memory, and interaction latency on representative low-end devices.
• Attach query and trace ids to widget diagnostics without logging sensitive filter values.
• Show generated-at and freshness metadata in the UI and alert when pipeline lag violates the metric's declared SLA.

06Security and accessibility boundaries

• Authorize metrics, dimensions, tenants, and row access on the server; hidden filters are not access control.
• Validate export limits and neutralize spreadsheet formulas in CSV cells derived from untrusted values.
• Pair every visualization with a title, summary, accessible table or equivalent data view, and keyboard-operable controls.
• Do not encode series by color alone; support contrast, zoom, reduced motion, and non-pointer inspection.

ANSOne full answer, start to finish

Drive the discussion yourself first. This is one strong answer delivered the way you would say it in the room — a model, not the only correct design.

The one thing to lead with: the browser should receive pre-aggregated numbers, not raw rows. Once you have said that, the rest of the answer is about making the dashboard feel responsive while several slow queries run — independent widgets, filter state in the URL, and any heavy client work pushed off the main thread.

1. Step 1 · Clarify

   Ask: 'How big is the underlying data — thousands of rows, or billions of events? How many widgets on a dashboard? Real-time or is a few minutes stale acceptable? And do users build their own dashboards or use fixed ones?' Assumptions: 'Very large event data, roughly 8 to 12 widgets per dashboard, a few minutes of staleness is fine, and users pick from fixed dashboards with adjustable filters.' The data-size answer is the whole design.

2. Step 2 · Requirements

   User-facing: pick a date range and filters, see charts and totals, drill in, and export. It must stay usable while data loads. Hidden: never freeze the UI, one slow query must not block the rest of the page, and a given view must be shareable as a link.

3. Step 3 · Aggregate on the server, not the client

   'For anything beyond a small dataset, the client gets pre-aggregated series — daily totals, top-10 breakdowns — computed by the query layer or a data warehouse. Sending raw rows to the browser leaks data, wastes bandwidth, and asks a phone to do a database's job. This is the single most important decision.'

4. Step 4 · Independent widgets

   'Each widget fetches and renders on its own. It shows a skeleton until its own query returns, and it has its own loading, error, and retry state. So if the revenue-by-region query is slow, the other five widgets still appear. The dashboard shell only owns the shared filter state.'

5. Step 5 · Filter state lives in the URL

   'The date range and filters are serialized into the URL query string. That makes any view a shareable, bookmarkable link and makes it survive a refresh. On load, the dashboard reads the filters from the URL and requests each widget's data with them applied. Changing a filter updates the URL and triggers the affected widgets to refetch, each showing its own loading state rather than blanking the whole page.'

6. Step 6 · Keep the main thread free

   'If any real computation remains on the client — say, a rollup the API cannot do — it goes in a Web Worker so scrolling and interaction do not stutter. And I canonicalize each query and drop responses whose key no longer matches the current filters, so a slow old response cannot overwrite fresh data.'

7. Step 7 · Rendering and accessibility

   'SVG charts up to a modest number of marks because they are semantic and easy to make keyboard-inspectable; canvas only for dense charts, and then with a separate accessible data table. Every chart gets a title, a short text summary, and a table view, and series are never distinguished by color alone.'

QAInterview questions and model answers