Design a metrics monitoring platform and dashboard for application and infrastructure time series. Services emit metric name, timestamp, numeric value, and labels. Users build dashboard panels over recent and historical ranges, aggregate by labels, and define alerts. Discuss ingestion, storage tiers, query execution, downsampling, cardinality control, and dashboard freshness. ### Constraints & Assumptions - Events may arrive late or be retried. - Recent dashboards need lower latency than long-range historical queries. - Unbounded label values can make a metric operationally unsafe. ### Clarifying Questions to Ask - What ingest rate, retention, and query latency are required? - Are counters, gauges, and histograms all supported? - How fresh must alerts be relative to dashboards? ```hint Separate recent and historical paths An in-memory or SSD-backed recent store can serve live panels while compacted object-store blocks serve long ranges. ``` ### What a Strong Answer Covers - Agent or gateway ingestion, batching, validation, durable buffering, and idempotency expectations. - A time-series key model, partitioning, compression, rollups, retention, and query planning. - Label-cardinality budgets, caching, alert evaluation, multi-tenancy, and observability. ### Follow-up Questions - How would you handle a label whose value is a request ID? - How would dashboard queries avoid overloading storage during an incident? - How would you support percentile queries from histogram data?