# Design Persistence for a Metrics Monitoring System Design the persistence layer for a metrics monitoring system so that it can support different query patterns. The source does not define the metric identity, sample shape, query language, scale, retention, or consistency semantics. Begin by eliciting those requirements, then state a coherent assumption set and show how the storage design follows from it. You may explore a conventional time-series model with timestamped values and dimensions, but treat that as a candidate design choice rather than a supplied requirement. Compare it with alternatives when the clarified queries call for a different shape. ### Constraints & Assumptions - No particular labels, filters, windows, aggregations, ingestion pattern, or rollup policy is given; state any such choices explicitly. - The persistence model should be evaluated against the query patterns selected during clarification, not against a generic claim that it supports every query efficiently. - Explain which data remains authoritative and which indexes, caches, or aggregates can be rebuilt. - Address growth, failure recovery, and schema evolution at the scale assumed in the answer. ### Clarifying Questions to Ask - What constitutes one metric and one observation: a scalar time sample, event, histogram, log-derived value, or another record? - Which queries matter most: exact lookup, recent series, time-window aggregation, grouping by dimensions, top values, alert evaluation, or ad hoc exploration? - What write rate, number of distinct series, retention period, result latency, and availability are required? - Can observations arrive late, out of order, or more than once, and what result should duplicates produce? - Must recent and historical queries use the same resolution and consistency model? ```hint Work backward from query keys List the filters, grouping fields, ordering, and time ranges for the important queries before choosing partition and index keys. ``` ```hint Separate a possible model from a source fact If you choose metric name, dimensions, timestamp, and value, explain why the assumed queries justify that representation. ``` ### What a Strong Answer Covers - A requirement-driven choice of record identity, partitioning, ordering, and indexes. - A concrete write path with an explicit policy for retries, duplicates, and late or corrected data under the chosen assumptions. - Query planning that uses the selected indexes and prunes irrelevant data rather than scanning the whole store. - A reasoned decision about raw retention, optional aggregates or rollups, and which statistics can be merged correctly. - Cardinality or skew risks that follow from the chosen schema, plus compaction, replication, and recovery. - Clear acknowledgment of which design decisions would change under different query requirements. ### Follow-up Questions - How would the design change if most queries ask for one recent series versus aggregations across many series? - When are precomputed rollups useful, and which statistics cannot be combined by averaging prior results? - What happens if one chosen dimension has nearly unbounded distinct values? - How would corrected historical data update any derived aggregates?