A metrics explorer is a versioned query workbench, not a chart with a text box. It separates draft edits from committed executions, derives a bounded resolution from time range and viewport, normalizes provider results into typed frames, guards each response by query revision, and stores only safe, reproducible state in the URL.
An explorer is used when the user does not yet know the answer. They may start with a metric name, add label filters, compare two environments, zoom into a spike, switch from graph to table, inspect the request cost, and send the exact investigation to a teammate. Each step changes a contract that the frontend must own deliberately.
The browser should coordinate query drafts, committed revisions, time range, resolution, request cancellation, result normalization, rendering, inspection, and shareable state. The service should authorize data sources, parse provider-specific queries, enforce budgets, execute work, normalize errors, and protect credentials.
Clarify the investigation workflow
Ask which metric languages and data sources are supported, whether users can run multiple queries, how absolute and relative ranges behave, whether live mode is required, how many series and points are safe, which chart and table views exist, what query statistics are exposed, how links are shared, and what permissions constrain metric names and labels.
For this design, assume an authenticated operations tool with a Prometheus-like first provider. A user can build several query rows, run them together, compare graph and table results, inspect execution statistics, zoom and brush a time range, enter live mode, and copy a reproducible link. Desktop is the authoring surface. Mobile supports reading, range changes, and basic query execution.
Alert-rule editing, dashboard layout, long-term metric storage, and implementation of the query language are separate systems.
The public interview prompt
Design a production metrics explorer. Explain:
- draft, committed, URL, cached, and rendered query state;
- metric discovery, label filters, variables, query validation, and multiple rows;
- absolute and relative time ranges, step calculation, downsampling, point and series limits;
- request generations, cancellation, partial results, warnings, statistics, and stale responses;
- provider adapters, canonical data frames, chart, table, exemplars, and query inspection;
- historical snapshots, live tail, cursors, overlap, deduplication, gaps, pause, and resume;
- shareable links, browser history, saved investigations, permissions, and redaction;
- accessible charts, keyboard inspection, internationalized time, performance, testing, and rollout.
What the premium solution covers
The complete solution builds a four-layer state model, a canonical query plan, an adaptive step budget, a provider-neutral frame contract, a revision-safe execution lifecycle, a historical-to-live seam, URL history policy, cost controls, accessibility alternatives, observability, testing, and an interview rubric.
Original media shows resolution increasing as the visible range expands, maps ownership across draft and committed state, normalizes provider results for graph and table views, and explains the snapshot-to-live handoff. Two deterministic labs let the reader tune point budgets and exercise URL history policy.