Design a Monitoring Dashboard with Explicit Latency Goals

Design a monitoring dashboard that displays incoming measurements with attention to latency. Explain both how quickly new measurements become visible and how quickly a user can load or change a chart. ### Requirements and Constraints For a concrete practice scope, assume producers emit timestamped numeric measurements with a metric name and a set of labels. Users choose a metric, label filters, and a time range to view a chart. These input and interaction details are exercise assumptions; no fixed throughput, retention period, freshness target, or response-time target is supplied. Describe the ingestion path, storage and aggregation choices, dashboard query path, and browser update mechanism. Show where delay can accumulate and how you would determine whether the system satisfies the latency requirement. Account for delayed measurements, overloaded ingestion, and a chart that becomes stale. ### Clarifying Questions - Does "latency" mean event-to-screen freshness, chart-query response time, or both, and how will each be measured? - Which time ranges and label filters must the dashboard support, and how many distinct label combinations can occur? - Can the display use aggregated points, and how should users see late or missing measurements? - Should a temporarily disconnected browser catch up on every measurement or fetch the latest chart state? ```hint Follow one measurement and one chart request A measurement can be delayed before it reaches storage, while a chart request can be slow even when storage is current. Trace these two paths separately. ``` ### What a Strong Answer Covers - Separate definitions for measurement freshness and interactive query latency, with a measurable end-to-end path for each. - An ingestion and storage design that supports time-range and label-filtered queries without making every chart scan all raw history. - A resolution or aggregation strategy that bounds work for wide chart ranges and identifies the effect on accuracy and late data. - A browser update strategy, including reconnection and a visible indication when the displayed data is stale. - Backpressure and capacity controls that address ingestion lag, expensive queries, and high-cardinality labels. - Measurements that locate delay in producers, transport, storage, query processing, and rendering. ### Follow-up Questions 1. How would you keep a month-long chart responsive without transferring every raw measurement to the browser? 2. What should happen when a late measurement changes an aggregate the dashboard has already displayed? 3. If chart queries remain fast while the newest displayed data becomes progressively older, which parts of the system would you investigate?